Тест "Кобаяси Мару" при приеме безопасника на работу

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

По сюжету «Кобаяси Мару» является космическим гражданским кораблем, который находясь в нейтральной космической зоне расы клингонов, оказался поврежден. У клингонов с людьми идет длительное конфликт и поэтому вмешательство тестируемого курсанта может негативно сказаться на развитии событий. Если попытаться спасти пассажиров «Кобаяси Мару», нарушив нейтралитет с клингонами, то это спровоцирует их на агрессию и возможно военный конфликт. Если выбрать невмешательство, то это значит дать гражданскому судну погибнуть. Это классическая дилемма с двумя безвыходными и негативными сценариями развития событий и надо выбрать из них только один. При этом в фильме компьютер, который и моделирует данную игру с курсантами, запрограммирован на проигрыш курсанта.

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

Вопрос достаточно простой на первый взгляд и он рано или поздно встает почти перед каждым безопасником (разница только в сумме). Вы можете пойти по традиционному пути и заложить эти деньги по принципу "так положено". А можете пойти по принципу "а вдруг" и договориться, что деньги будут выделены, если организация попадет в перечень плановых проверок РКН (но тогда причем тут лицензиат ФСТЭК и защита ПДн?). А можно пойти по бизнес-сценарию и принять как данность, что даже в худшем сценарии развития событий сумма штрафа составит на порядок меньшие деньги заложенных в бюджет и можно принять риск несоответствия, потратив деньги на более реальные бизнесу нужды. Причем тут нет правильного ответа (все как в тесте "Кобаяси Мару"). В любом случае вы что-то теряете - деньги бюджета на бесполезное приведение себя в соответствие или репутацию в случае прихода регулятора и сумму штрафа? Что выберет кандидат? На выбор будет влиять его бизнес- или compliance-ориентированность, которая и может стать предметом анализа в рамках данного теста.

Чем не идея? Среди других тестов "Кобаяси Мару" в ИБ может быть проверка дилемм "отечественное или зарубежное средство защиты", "open source vs коммерческое ПО", "своя система защиты vs аутсорсинг"...

ЗЫ. В фильме Джеймс Кирк проходит этот тест (единственный курсант в оригинальной вселенной "Звездного пути") просто "взломав" компьютер и изменив программу. Это позволяет проверить если не характер, то оригинальность мышления кандидата, что тоже может быть одной из задач теста.

Новая триада законодательства по финансовой безопасности (презентация)

Еще одной темой презентации, прочитанной мной на Payment Security, стало новое законодательство, применимое к финансовым организациям. Это и пресловутый ФЗ-187, и новая редакция 382-П и ГОСТ 57580.1. Вот об этой триаде (хотя к ней можно было бы добавить и удаленную идентификацию) я и говорил в Питере. Вроде ничего нового, но вдруг кому-то будет интересно :-)

Новая триада законодательства по финансовой безопасности from Aleksey Lukatskiy

Сегодня для обнаружения атак недостаточно систем обнаружения атак (презентация)

На прошедшей на прошлой неделе в Питере Payment Security довелось мне вернуться к истокам - к теме обнаружения вторжений, которой я начинал заниматься в 98-м году и про которую написал в 2000-м свою первую книгу. Прошло 20 лет, а некоторые отечественные разработчики так и застыли в том времени, используя те же самые подходы к разработке средств обнаружения атак/вторжений. Отчасти это связано с нормативной базой, которая и задает тон для российских разработчиков. Но сегодня обнаружение атак - это не тоже самое, что и 20 лет назад. Этот очевидный тезис не столь очевиден для многих потребителей, которые по-прежнему живут в парадигме "для обнаружения атак надо использовать СОВ/СОА". Но за прошедшие пару десятилетий изменилось многое - атаки, технологии, подходы, архитектуры. И все это надо учитывать при выстраивании системы обнаружения атак на предприятии. Именно системы, а не средства. Одним продуктом это не решить (какой бы он ни был). Этому и была посвящена презентация, которую я выкладываю в блоге.

Обнаружение атак - из конца 90-х в 2018-й from Aleksey Lukatskiy

ЗЫ. Я знаю, что SlideShare недоступен для многих пользователей из-за блокировки LinkedIn. Но обойти это ограничение не составляет большого труда.

Broadcom покупает CA

11 июля компания Broadcom, один из лидеров рынка поставщиков полупроводников, согласился купить компанию CA за почти 19 миллиардов долларов. Зачем это Broadcom не совсем понятно - не повторилась бы история с Intel и McAfee. Но будем посмотреть...

Фиды - это еще не Threat Intelligence

“А у вас есть фиды?” - так часто начинается разговор наших заказчиков, которые обращаются к нам с вопросом о наличии у нас решений класса Threat Intelligence. “А у нас есть фиды!” - так часто звучит доказательство наличия системы TI в организации. Но фиды - это еще не Threat Intelligence, это скорее попытка заговорить о создании программы TI (или CTI, Cyber Threat Intelligence) в организации. Хотя и просто работа с фидами - это тоже непросто. Как, например, понять, когда полученный в рамках обмена фидами индикатор в виде IP-адреса вредоносного узла необходимо перестать учитывать, потому что он был "вылечен"? Или вот реальный свежий пример. Приходит в рамках информационного обмена индикатор в виде имени домена, который надо блокировать, а там "media.kaspersky.com"!!! С какого перепуга, спрашивается? Начинаешь переписку, а тебе в качестве доказательства вредоносности приводят статью из New York Times, где говорится, что продукты ЛК шпионят за пользователями. Просишь доказательств, а их нет. И как верить такому источнику? А ведь можно вспомнить и историю с Гризлигейтом, когда Россию обвиняли почем зря во вмешательстве в американские выборы и приводились "какие-то" индикаторы, которые с тем же успехом могли играть и против американцев. А ведь это только фиды. В категории уровней TI - это самый нижний, технический уровень.

Выше у нас еще есть тактический уровень, на котором надо оперировать тактиками, техниками и процедурами (TTP). Помните, в ноябре 2016-го я писал об этом? В пирамиде это самый верхний и самый непростой уровень для сбора информации. Да, мы можем использовать ATT&CK, но как формализовать описание методов злоумышленников? Тоже непростая задача; особенно в условиях повального импортозамещения, когда все западные продукты, использующие ATT&CK в своей работе, не могут быть использованы многими российскими предприятиями, а российские продукты вообще не используют ATT&CK в своем функционале.

Но допустим мы решили и эту проблему, какие сложности встают перед нами? Второй по поулярности вопрос после "а у вас есть фиды", звучит так: "А можете прислать ссылок на источники фидов и желательно бесплатных?" :-) Ох уж это неискоренимая жажда халявы :-) Ну да ладно, есть такие списки и предоставляемые ими фиды вполне себе неплохи на первых порах (с учетом ранее описанных нюансов).

А где их хранить все эти фиды и описание TTP? А как поднять с тактического уровня на операционный и оперировать уже целыми кампаниями? Как от разрозненных индикаторов перейти к пониманию того, что против нас действует целая группировка и уж точно попадание в логи МСЭ или IPS IP-адреса из присланного фида является неслучайным совпадением? Для этого нам нужны платформы Threat Intelligence (TIP), которые могут быть коммерческими и бесплатными, закрытыми и открытыми, зарубежными и отечественными. А не накроется ли выбранными нами TIP медным тазом, как это произошло с Soltra)? Есть ли у нас план Б на этот случай?

И конечно не стоит сбрасывать со счетом TI, предоставляемый нам государством, ГосСОПКОЙ или ФинЦЕРТом. В чем их сила, а в чем слабость? Это тоже вопросы, которые требуют ответа. Правда, с ГосСОПКОЙ пока все ясно - там нет ничего, что можно было реально использовать, - ни достаточного количества данных, ни ясной процедуры подключения, ни утвержденных стандартов обмена данными об инцидентах.

Кстати, о стандартах. Какой их них выбрать? STIX, используемый большинством компаний в мире и ставший по сути стандартом де-факто в этой области? CybOX? А может отечественный СТО 1.5, разработанный Банком России, и требуемый для взимодействия с ФинЦЕРТом? А что будет использовать ГосСОПКА (кроме TLP)? Не получится ли так, что мы сейчас выберем то, что не будет поддерживаться ни регуляторами (куда уж без них), ни отечественными разработчиками (хотя вот BI.ZONE в своей платформе обмена данными использует расширенный вариант STIX).

Но допустим мы выбрали платформу, выбрали источники фидов, научились описывать не только отдельные индикаторы и целые компании, но даже смогли подняться на стратегический уровень TI (он не всем нужен, кстати) и заняться атрибуцией нарушителей (со всеми оговорками, которые связаны с данной процедурой). Как измерить процесс Threat Intelligence? Как понять, что и сам процесс работает эффективно, и используемые нами источники дают ценную информацию, которую мы действительно используем, а не просто складируем в TIP?

Много вопросов набежало, не правда ли? Вот о них мы и будем говорить в рамках мастер-класса, который я буду вести на "Код ИБ. ПРОФИ" в Сочи через две недели (регистрируйтесь - места еще вроде остались). Это помимо проводимых мной там киберучений. Понятно, что задача это будет непростая - вложить в 1 час столько материала. А я его перелопатил много, когда готовился к конференции. Имеющийся личный опыт и опыт службы ИБ Cisco будут наложены на более чем 300 различных источников (стандартов, Best Practices, книг, презентаций и т.п.), которые я проанализировал и систематизировал. Десятки часов изучения будут скомпонованы в одну презентацию длительностью 1 час. Понятно, что в эти 60 минут все 300 материалов уложить сложно, но я попробую (систематизация у меня всегда получалась хорошо). В любом случае скучно не будет, а материал будет иметь практическую направленность, которую можно будет применять сразу по возвращению в свой город. И да, презентацию я выкладывать не буду, как не делал этого и по киберучениям, - за участие в мероприятии и доступ к этому контенту люди платят деньги и было бы неправильно выкладывать в паблик то, за что люди тратят свои кровные или финансы своих компаний.

Thoma Bravo покупает Centrify

Частный инвестиционный фонд, хорошо известный в области поглощения на рынке ИБ, Thoma Bravo, объявил 10 июля о намерении приобрести одного из игроков рынка контроля привилегированного доступа, компанию Centrify. Размер сделки не разглашается.

AT&T покупает AlienVault

10 июля американский провайдер AT&T объявил о планах по приобретению компании AlienVault, известного разработчика SIEM (коммерческого USM и бесплатного OSSIM) и поставщика Threat Intelligence. Размер сделки не разглашается.

Будущее криптографии: гомоморфное, медовое, функциональное и ДНК-шифрование

Завершу все-таки начатую тему про будущее криптографии (вдруг доживем) упоминанием еще нескольких направлений, который сейчас достаточно активно прорабатываются в индустрии (помимо постквантовой криптографии и нейросетей):

• Медовое шифрование. Когда я только начинал изучать криптографию, то я задавался вопросом: "А как при автоматизации процесса дешифрования понять, что мы получаем правильный текст и как отличить один набор получаемых символов от другого?" И вот проблема, лежащая в основе этого вопроса, легла и в основу нового метода шифрования под названием "медовое". Когда криптоаналитик пытается дешифровать шифртекст с помощью неверного ключа он получает бессмысленный текст; в случае с медовым шифрованием криптоаналитик получает вполне осмысленную последовательность. И злоумышленник даже не понимает - он получит реальный открытый текст или фальшивый? Интересный проект.
• Гомоморфное шифрование. Когда мы используем обычное шифрование, то мы сталкиваемся с ситуацией, к которой мы привыкли и даже не считаем ее проблемой. Чтобы поработать с зашифрованными данным мы их должны расшифровать и тогда они могут стать достоянием злоумышленников. Гоморфное же шифрование подразумевает, что вы можете проводить операции над зашифрованным текстом и получать вполне адекватный результат без расшифрования текста. Например, такую схему можно использовать в электронных выборах (подсчет голосов при сохранении анонимности избирателей), в облачных вычислениях, при защищенном поиске (выдача результата без анализа его реального содержимого) или в системах с обратной связью и т.п. И хотя идея гомоморфного шифрования была сформирована 40 лет назад, первый полностью гомоморфный алгоритм появился только в 2008-м году, но до сих пор все такие системы являются крайне низкопроизводительными, что и ограничивает их активное применение в реальной жизни. 
• Функциональное шифрование. С одной стороны функциональное шифрование, предложенное в 2005-м году, базируется на идее шифрования с открытыми ключами, а с другой - в нем передается не зашифрованное сообщение, а зашифрованная функция, которая позволяет по аналогии с гомоморфным шифрованием обеспечить защиту данных не расшифровывая их целиком. Например, одним из сценариев применения такой схемы является защита программного обеспечения от анализа злоумышленниками. После его функционального шифрования мы получаем эквивалентный по функциональности, но недоступный для анализа, обфусцированный исходный код. Помимо защиты интеллектуальной собственности функциональное шифрование может быть применено и в облачных вычислениях.
• ДНК-шифрование. В 1994-м году Леонард Адлеман (ему "принадлежит" буква А в алгоритме RSA) предложил идею использования ДНК для осуществления вычислений путем манипулирования молекулами, что позволяет производить параллельно триллионы операций. В отличие от бинарной логики современных компьютеров и кубитов квантовых компьютеров у ДНК-вычислений код тернарный (на основе 4-х оснований), что и обеспечивает огромную скорость вычислений. Однако извлечение результата вычислений из ДНК осуществляется гораздо медленнее, что пока и сдерживает активное их использование, в том числе и для криптоанализа.

Ну вот, пожалуй, и все тенденции криптографии, о части из которых (например, о гомоморфных системах) можно почитать на сайте РусКрипто, где немало делалось докладов на эту тему. Но найдут ли эти подходы свое применение в России в ближайшее время, не знаю...

PS. Кстати, у Siri очень забавные поисковые ассоциации с описанными в заметке вариантами шифрования :-)

ФСТЭК определилась со своим будущим

Долго думал, писать эту заметку или нет, но в итоге несколько встреч, произошедших за пару недель, пересилили желание обойти тему молчанием. За последние полгода в ФСТЭК было проведено немало различных совещаний и методических сборов, как в рамках тематики КИИ или защиты государственных информационных систем, так и в области стандартизации (ТК362) или сертификации средств защиты информации (новые требования по сертификации, новые РД и т.п.). В итоге у меня сформировалась картина того, куда сейчас движется ФСТЭК. Допускаю, что я могу ошибаться в оценке действий регулятора, но высказанное не раз мнение от разных сотрудников ФСТЭК, заставляет меня думать, что это все-таки не случайность, а осознанный курс, который надо учитывать в собственной стратегии ИБ. Итак важных на мой взгляд изменений грядет четыре:

1. ФСТЭК прямо заявляет, что они фокусируются на защите государственных органов и КИИ. Это вроде уже не новость - ФСТЭК об этом говорит уже не первый раз, дистанцируясь и от темы ПДн (проверять-то они не могут операторов ПДн), и от темы НПС (проверять участников НПС они тоже не проверяют, "делегировав" это Банку России), и от ряда других тем, где они не названы уполномоченным органом, имеющим всю полноту власти. То ли дело КИИ и госы, где ФСТЭК чувствует себя как рыба в воде и может выпускать любые приказы и регламенты и проверять их исполнение. Этот пункт важен в контексте всех последующих шагов и означает, что коммерческим организациям не стоит ждать откровений и решения всех своих вопросов и проблем - в порядке живой очереди, но госы все равно имеют приоритет.
2. Из пункта номер один вытекает пункт №2 - обязательную сертификацию ФСТЭК требует только для госорганов. Точка. Все, что придумывают остальные регуляторы (ЦБ в своем ГОСТе или 382-П, Минздрав в 447-м Постановлении Правительства от 12 апреля 2018 года), это все головная боль не ФСТЭК, а придумавших это регуляторов. И как будет осуществляться сертификация АБС по ОУД4 или прикладных систем, подключающихся к единой системе в сфере здравоохранения, об этом пусть думают регуляторы, установившие это требование.
3. Из пункта 1 и 2 вытекает пункт 3. Так как ФСТЭК ориентирован на госы и обязательная сертификация требуется только для госов, то ФСТЭК сейчас начинает говорить о вполне закономерном шаге, который должен повысить безопасность подопечных регулятора. Речь идет об установке "грифа" ДСП на документы ФСТЭК, в том числе и на требования по сертификации (я не буду вдаваться в детали, какие документы уже имеют такой гриф, а какие планируют его получить). Логичный вопрос для банка "а как мне устанавливать требования к средствам защиты, которые по требованию ГОСТа ЦБ должны быть сертифицированы, если РД на эти средства может быть закрыт для посторонних?" на самом деле не является головной болью ФСТЭК. Не они от банков требовали сертификации (они кстати выступали против принятия ГОСТа на заседании ТК122). Не они регулируют финансовые организации. Не им и отвечать. Это ЦБ должен думать, как доводить до всех тысяч финансовых организаций дспшные требования. То ли требовать от всех лицензию на гостайну получать, то ли лицензию на ТЗКИ. Но оба пути в никуда :-(  
4. Из первых двух пунктов вытекает и последняя замеченная мной тенденция - ФСТЭК постепенно отказывается от "Общих критериев" в сторону старых добрых требований к классам защищенности. Возможно это геополитически и не совсем верно, но зато проще для всех участников процесса сертификации по требованиям безопасности. Лаборатории не будут задумываться, как писать профили защиты и задачния по безопасности (это долго, дорого, и не всегда очевидно как, не имея опыта в этом процессе). Заказчики (читай, госы) четко будут понимать, что им требовать от вендоров. Вендора смогут понятным языком объяснять, какой функционал есть в их продуктах и как он накладывается на классы защищенности. Отсюда возникает вопрос, связанный с недавно принятой новой редакцией 382-П, обязывающей сертифицировать банковские и финансовые приложения на ОУД4 по линии ФСТЭК. Если лаборатории постепенно будут "забывать" про "Общие критерии", то найти того, кто возьмется за сертификацию и постоянное обновление сертифицированного изделия (а ЦБ постоянно что-то меняет в своей нормативке, что приводит к изменениям в ПО) будет непросто и недешево.

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

1. Десять раз подумайте, нужна ли вам обязательная сертификация средств защиты, если государство от вас этого не требует на уровне ФЗ или ПП.
2. Живите свои умом, но не забывайте поглядывать и в сторону документов ФСТЭК. Они написано здраво и не требуют сверъестественного. Более того, алгоритм выбора защитных мер оттуда гибкий и позволяет учесть кучу нюансов современной организации бизнеса.
3. Не стоит забрасывать ФСТЭК запросами и письмами, на которые ответ либо будет расплывчатым, либо неустраивающим вас. Фактически ФСТЭК не регулирует вопросы защиты информации ни у кого, кроме госов и КИИ. Так зачем спрашивать то, на что у ФСТЭК нет ни полномочий, ни опыта, ни, следовательно, четкой позиции.
4. Не ждите каких-то разъяснений, которые сделают вашу жизнь легче. А дальше см.п.3. И даже для КИИ не стоит ждать от регулятора манны небесной и ответа на вопросы: "А как мне категорировать мои объекты КИИ?", "А где мне провести границы объекта КИИ?", "А я субъект КИИ?", "А я могу объединить несколько объектов КИИ в один?". Помните, что в отличие от коммерческой организации, живущей по принципу "все, что не запрещено явно, разрешено", ФСТЭК, как и любой госорган, следуют прямо противоположному принципу - "Все что не разрешено явно, запрещено". Ну откуда ФСТЭК знает, как категорировать подстанцию, ТЭЦ, АЗС, автовокзал или районную больницу? Не она же управляет ими и не она обладает исходными данными для категорирования. Она может оценить (и то за ограниченное время) правильность ваших действий, но не решить это за вас. Да и правильность ФСТЭК оценить может только спустя какое-то время, получив опыт работы с кучей актов категорирования. 

Ну вот как-то так...

Комната для SOC: освещение и вентиляция, а также реверберация и кактусы на мониторах

После 12-ти минут непрерывного мониторинга оператор пропускает 45% активности на мониторе, после 22-х минут - до 95%. В целом после 20-40 минут активного мониторинга оператор систем охранного телевидения сталкивается с психологической слепотой и перестает распознавать любые объекты. Думаю, что у аналитиков SOC цифры не сильно отличаются. И возникает вопрос, как не ухудшить эти показатели? В прошлой заметке про количество мониторов я не стал касаться еще одной темы, связанный с помещением для SOCа. Поговорим о ней сегодня.

Когда Cisco много лет назад выводила на рынок технологию TelePresence, мы на первых порах, если мне не изменяет память, столкнулись с проблемой недовольства клиентов тем, что они не получали обещанный эффект присутствия. В результате первых пилотов, выяснилось что оборудование ставилось в обычные кабинеты, где раньше стояли ВКС-системы. Отсюда и недовольство - комнаты оказались неприсособленными для TelePresense. Отсутствие правильного освещения, акустики, эстетики, сказывалось на впечатлении заказчиков и эффективности проводимых переговоров. В результате у нас родилось руководство по проектированию комнат для TelePresence (советую посмотреть - там многие моменты применимы не только к TelePresence).

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

• Освещение
• Блики на мониторах, которые могут быть нейтрализованы специальным светоотражающим или утопленным освещением, а также отсутствием окон или использованием на окнах штор или жалюзи для снижения яркости естественного освещения.
• Помните, что окна имеют психологическое значение и их отсутствие приводит к негативному эффекту.
• Теплота, освещенность и яркость освещения.
• Акустика
• Шумопоглощение. Как поглощается звук с улицы? А звук из коридора или соседних комнат? Двери стоит тоже изолировать, например, с помощью специальных акустических панелей. Может быть это не так важно, но стоит проверить как звук проходит не только извне внутрь SOC, но и наоборот. А то иногда звучащий внутри SOC мат может достигать и внешних помещений :-)
• У вас в SOCе есть большие экраны? А как на них выводится изображение? Через большой и громко шумящий проектор? Как бороться с такой проблемой?
• А как комната SOC борется с эхо (отражение звука), реверберацией (затухание звука)? Эти звуковые явления могут не только мешать переговариваться аналитикам SOC в одном помещении, но и мешать при проведении переговоров с другими группами аналитиков, а также изолировать сигналы тревоги, издаваемые в случае обнаружения угрозы (такие сигналы должны отличаться от обычного фонового шума).
• Наконец, подумайте о шумах от вентиляторов, чайников и других приборов, которые могут отвлекать аналитиков от своей работы. Они, кстати, могут не только шуметь, но и вибрировать.

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

Я не планировал в одной заметке описать все возможные нюансы, возникающие при создании центров мониторинга. Просто мне хотелось обратить внимание на моменты, которые не часто рассматриваются в реальной жизни и уж совсем не озвучиваются на различных мероприятиях. По крайней мере я не помню ничего такого на всех наших SOC Forum'ах; да и на американских SOC Summit'ах тоже. Мы когда строим SOCи или оцениваем их зрелость обращаем на эти моменты внимание. Но что делать тем, кто не может обратиться к Cisco?

Я бы посоветовал взглянуть на стандарт ISO серии 11064 про эргономичное проектирование центров управления. В преамбуле к нему написано, что стандарт применим ко всем типам центров управления, включая центры управления, предназначенные для промышленных технологических процессов, транспортных и диспетчерских систем и аварийных служб. Основное предназначение стандарта - стационарные центры управления, но многие его принципы могут быть применены к мобильным центрам, расположенным, например, на кораблях, локомотивах и в самолетах (эээх, SOC на океанской яхте, классно же).

Многие стандарты этой серии переведены на русский язык и приняты в качестве ГОСТа:

• ГОСТ Р ИСО 11064-1-2015 Эргономическое проектирование центров управления. Часть 1. Принципы проектирования
• ГОСТ Р ИСО 11064-2-2015 Эргономическое проектирование центров управления. Часть 2. Принципы организации комплексов управления
• ГОСТ Р ИСО 11064-3-2015 Эргономическое проектирование центров управления. Часть 3. Расположение зала управления
• ГОСТ Р ИСО 11064-4-2015 Эргономическое проектирование центров управления. Часть 4. Расположение и размеры рабочих мест
• ГОСТ Р ИСО 11064-5-2015 Эргономическое проектирование центров управления. Часть 5. Дисплеи и элементы управления
• ГОСТ Р ИСО 11064-6-2016 Эргономическое проектирование центров управления. Часть 6. Требования к окружающей среде
• ГОСТ Р ИСО 11064-7-2016 Эргономическое проектирование центров управления. Часть 7. Принципы верификации и валидации

И вновь повторю свое заключение из прошлой заметки - проектируя SOC, занимаясь TI-платформами, SIEMами, Stealthwatch'ами и другими компонентами центра мониторинга, не забывайте и про помещение для него, его юзибилити и эргономику рабочих мест, от которых заависит, насколько комфортно, а значит эффективно, будут работать его аналитики и обнаруживать угрозы.

Разделенное внимание, мнимая многозадачность и количество мониторов в SOC

Наверное многие видели фотографии SOCов с огромными экранами, на которых что-то показано красивое и переливающееся всеми цветами радуги. А вы знаете, что по статистике, эти экраны не используются в 80% времени, исключая приходы руководства, СМИ (если компания важная) и важных клиентов.

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

Но на самом деле человек не способен работать в многозадачном режиме. Многие компьютеры тоже это не умеют несмотря на термин "многозадачность" (если не брать в расчет многопроцессорные или распределенные системы). Просто разные задачи распределяются между тактами процессора и переключение между задачами происходит незаметно для человеческого глаза. А вот человеческий мозг так не умеет (ну если вы не Юлий Цезарь, конечно). Более того. Мнимая человеческая многозадачность приводит к замедлению работы и забывчивости. При переключении мы откладываем дела в краткосрочную память и можем забыть до 40% в ней хранящегося, то есть того, что делали и планировали делать. Вот, посмотрите ролик, в нем как раз хорошо показан результат переключения с задачи на задачу:



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

В этой области (change blindness) проводится достаточно много различных исследований, особенно военными, у которых цена ошибки достаточно высока. В частности, ВМС США проводили такое исследование "Verification of the change blindness phenomenon while managing critical events on a combat information display" с целью определить, каков процент изменений на мониторах упускают из ввиду операторы ВВС, следящие сразу за несколькими мониторами. Согласно многочисленным исследованиям, на полное восстановление состояния глубокой концентрации после отвлечения на другие задачи, уходит примерно 15 минут. Иными словами, использование двух и более мониторов, отображающих разные типы информации, может негативно сказаться на способности концентрировать внимание. Это иная сторона психологической слепоты, о которой я уже писал в октябре.

А сколько мониторов нужно для того, чтобы работа аналитика SOC была максимально эффективной? Если честно, то я не нашел ни одного исследования, дающего ответ именно на этот вопрос. Но есть исследования, которые отвечают на вопрос относительно числа мониторов у операторов систем охранного видеонаблюдения. Согласно исследованиям, при использовании одного, четырех, шести и девяти мониторов, точность обнаружения составляет 85%, 74%, 58% и 53% соответственно. В различных материалах говорится, что чем критичнее область контроля (например, казино или алмазные компании), чем меньше мониторов используется - не больше 3-4-х. В SOCе же объекты контроля не только меньше, но и менее заметные, чем у видеонаблюдения, поэтому и мониторов должно быть меньше. Если бы мы наблюдали только за DDoS, то мы могли бы использовать больше мониторов, но увы... бывают и другие, менее заметные атаки, а значит число мониторов не должно быть большим. Тем более, что одна атака может скрываться за другой, отвлекающей внимание, и концентрация внимания у аналитика должна быть достаточно высокой - большое число мониторов только распыляет его концентрацию.

Бороться с описанной проблемой можно несколькими путями:

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

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

ЗЗЫ. Карты атак тоже бессмысленны для больших экранов. Да и вообще бесполезны.