Что я жду от конференции ФСТЭК и от РусКрипто?

Уже по традиции февраль стал месяцем, в котором проходит два мероприятия главных регуляторов по ИБ - ФСТЭК России и Банка России. Первый проводит свою юбилейную, уже десятую конференцию "Актуальные вопросы защиты информации". Думаю, что юбилей вряд ли будет как-то с помпой отмечаться, но контент, который должен будет представить регулятор, представляет, как и обычно, интерес. Учитывая, что на вчерашнем Инфофоруме уже было выступление Лютикова В.С., который высказался по 3-м ключевым направлениям - КИИ, сертификация и проблема кадров. Именно последняя тема, озвученная (на 45:40 мин) заместителем директора ФСТЭК, на последнем SOC Forum, вызвала бурную дискуссию в соцсетях. В программе конференции 12-го февраля этой темы нет, но зато чуть ли не половина докладов будет посвящена вопросам сертификации средств защиты информации по введенным недавно требованиям (тут и 55-й приказ, и требования по доверию, и планы по развитию БДУ).

Возможно будут озвучены в очередной раз планы по выпуску и разработке новых РД к средствам защиты, тем более, что те же требования к СУБД, упомянутые несколько лет назад, так и не появились, а с тех пор разрабатывались также требования, как минимум, к средствам отражения DDoS-атак. Я "пробежался" по прежним выступлениям регулятора и посмотрел на его обещания/планы в части выпуска новых требований к средствам защиты. Видно, что от года к году аппетит регулятора снижался и если в 2016-м году и ранее ФСТЭК хотела охватить своими требованиями все средства защиты, которые могут реализовывать меры из 17/21/31-го приказов, то в 2017-м году в планы попали только три документа, а в прошлом году новых документов вообще не обещали - только обновление. Правда, даже этого, не говоря уже о новых документах, отрасль не дождалась.

Как не дождались и обещанной методички по защитным мерам для АСУ ТП (а теперь и для объектов КИИ). В начале февраля в Фейсбуке прозвучала критики регулятора, которому советовали посмотреть в сторону NIST или CIS, которые активно привлекают сообщество к разработке документов, что приводит не только к росту качества, но и к скорости выхода документов. Но ФСТЭК в последнее время от псевдо-краудсорсинга вообще отходит и делает все своими силами, навешивая на документы пометку "для служебного пользования" (видимо, чтобы враги не узнали о том, как надо защищаться).

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

ФСБ в феврале нас не радует. Ее месяц - ноябрь, когда представители НКЦКИ рассказывают про тематику ГосСОПКИ на московском SOC Forum. Другие мероприятия они не жалуют, исключая, пожалуй, РусКрипто (и СТСrypt). Раньше, покойный Кузьмин А.С. выступал на РусКрипто и делал программный доклад о перспективах регулирования криптографии в России, а затем его тему подхватывали другие сотрудники ФСБ. Последние годы я не помню схожих докладов от руководства 8ки (а сейчас оно еще и поменялось снова). Но в любом случае, судя по программе РусКрипто, которая пройдет в марте, там можно будет узнать позицию регулятора и по теме, связанной с новым законом об электронной подписи, и про квантовую (и, возможно, постквантовую) криптографию, и про криптографию в IoT и транспорте, и про криптографию в энергетике и финансовой отрасли, и т.п. Я планирую выступать на РусКрипто с докладом "Эволюция систем управления идентификационной информацией" (про MFA, биометрию, мультиоблачную стратегию, идентификацию устройств и т.п.).

7 уроков из сотен расследованных инцидентов

Наткнулся я тут на презентацию службы реагирования на инциденты Cisco, которая по результатам более 100 проведенных расследований у наших заказчиков, сформулировала 7 ключевых наблюдений/уроков, которые мне показались достаточно интересными, чтобы про них написать. Ну а учитывая, что они не касаются продуктов, то это не стоит рассматривать как product placement.

Helpdesk всегда знает, где закопано тело

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

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

Следите за изменениями

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

Хакеры знают сеть лучше админов

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

Сегментация и доступ

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

Хакеры редко используют 0Day

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

Редактирование выбора пользователей 

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

Будьте бдительны при закрытии инцидента

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

В качестве финального аккорда отмечу еще несколько сделанных наблюдений:

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

Как перестать тратить время на ерунду

На прошлый Новый год самым популярным стало пожелание в мой адрес находить время на все мои проекты. Потом, уже на праздники, в отсутствие компьютера, было время подумать. А куда я трачу свое время? И понял я, что многие проекты, которые я хотел начать и даже начал, так и не были начаты или завершены. А все потому, что я тратил свое время слишком расточительно и все не по делу. Точнее я думал, что по делу, но если вдуматься и оценить результаты, то… они плачевны.

Но тут, очень кстати, я наткнулся на заметку “Важность погружения в работу: метод 30-ти часов для изучения новых навыков“. В ней было немало отсылок к книге “Deep Work: Rules for Focused Success in a Distracted World”, которая была издана и на русском языке с совершенно иным, и на мой взгляд, не очень удачным названием - “В работу с головой. Паттерны успеха от IT-специалиста” (кстати, deep work лучше переводить как “глубокая концентрация”, чем как “глубокая” или “сфокусированная работа”).

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

В итоге я перескакиваю от одной темы к другой, не погружаясь в них, так и не став окончательно экспертом в каждой из них (кто бы там, что не считал). Стал замечать, что во многих темах ИБ у меня поверхностные знания и число таких тем стало неприятно расти. Перескакиваю с темы на темы, пролистываю интересные статьи, вместо того чтобы их читать (а то и вовсе откладываю статьи “на потом”, которое никогда не наступает), трачу время на соцсети (хотя лимиты времени для разных приложений в iOS 12 - это классно - сразу себе поставил лимит на соцсети), отвлекаюсь на проверку почты. Вроде и занят постоянно, и делаю что-то “полезное” и “нужное”, но удовлетворяющего меня результата не было. Даже в блог стал писать гораздо реже, не говоря уже о заброшенных новых книгах. Это мой портрет в 2019-м году (а может и раньше).

Тоже самое касается и тех, кто пытается разобраться в чем-то новом. Материалов, даже бесплатных, сегодня выше крыши. А разбираться в них никто не хочет/не может. За что браться? За все и сразу? Фокусируйтесь и обрящете :-) Согласно многим исследованиям эксперта отличает от обычного специалиста именно умение глубоко концентрироваться и погружаться в проблему/задачу, что в итоге и дает ему более глубокие знания и, как следствие, преимущества по сравнению с другими, более поверхностными специалистами.

Что нужно делать? Из упомянутой выше книжки я выделил несколько идей и мыслей:

1. Составьте список задач, которые потребуют глубокой концентрации. Тут можно применить матрицу Эйзенхауэра, чтобы понять, что действительно нужно и важно, а что просто сжирает все время без пользы.
2. Определите цель/цели своего проекта/задачи/проблемы. Без этого ваша концентрация ни к чему не приведет - работа будет проходить впустую. Вы должны двигаться куда-то конкретно, а не просто двигаться. Если ваш проект достаточно крупный (например, написание книги), то проведите декомпозицию и разбейте цель на подцели (например, книгу на разделы и главы).
3. Концентрацию нужно тренировать. Есть различные техники и даже приложения для iPhone или компьютера.
4. Исключите все отвлекающее - телефон, соцсети, напоминалки и уведомления, бездумный серфинг… Чтобы войти в состояние фокуса на какой-то задаче/проблеме нужно не менее 25 минут. Поэтому если вы отвлекаетесь на что-то раз в 20 минут, то вы не сфокусированы на работе и результата нет. Режим контроля экранного времени в iOS - классная штука. На ноутбуке я использовал раньше RescueTime, но на Cataline он не работает (но зато там появился режим контроля времени как в iOS). Начинал я в режиме контроля, а сейчас стал более активно использовать блокирование по таймеру (те же соцсети и иные бестолковые ресурсы). 
5. Выделяйте время на работу, требующую глубокой концентрации. В статье говорится о 4-х семичасовых блоках, но на мой взгляд, это сложнореализуемая идея для большинства. 3-4-часовые блоки выглядят гораздо реалистичнее и выделять их надо во времена наибольшей работоспособности, которые у каждого свои (утром или вечером). Но делать это надо регулярно. Есть и еще один способ - “уйти в монастырь”, то есть полностью удалиться от мира сего на день или более, полностью отдавшись проекту/хадаче/исследованию/книге/статье. Это тяжело и не всем доступно. Третий вариант заключается в том, чтобы посвящать своему проекту целиком один или два дня в неделю, остальное время оставляя под “рутину”. Но это маловероятно для рядового безопасника, который помимо чего-то большого и светлого занимается еще и кучей повседневных задач.
6. Заранее спланировать свой день, то есть сделать это вечером предыдущего дня. Это классика тайм-менеджмента.
7. Легкий челендж. Я последнее время живу в режиме дедлайна. Презентация в последнюю ночь (на самом деле это еще и потому, что выступлений слишком много и заранее я их не успеваю готовить), продумывание сценария киберучений в последнюю ночь, разработка вопросов для “Нашей игры” в последнюю ночь… Тоже самое можно превратить в более управляемый процесс. Считается, что в условиях легкого стресса мы более эффективны. Заплатите за коворкинг для реализации проекта - это заставит вас не тратить время попусту и не отвлекаться. Читая статьи или книги, не отбрасывайте неизвестные слова. Лучше потратьте время на изучение того, что за ними скрывается. Озвучьте публично дату какого-либо мероприятия (или подайтесь для выступления на нем) и вы вынуждены будете к нему готовить контент. Да, это неприятно, но это челендж и он нужен.
8. Отдыхайте. Я работаю за ноутбуком. И занимаюсь любимым делом там же. Это хорошо и плохо. На новогодние праздники за комп вообще не садился - зато каждый день коньки, прогулки по заснеженному поселку, чистка дорожек от снега и т.п. Это разгружает мозг и потом дает возможность быть более скоцентрированным. Да и идей новых дает.

Как перейти от эфемерных угроз к реальным техникам злоумышленников?

8 марта 2020 года. Ваши коллеги празднуют женский день, а вы вынуждены разрабатывать модель угроз по недавно утвержденной методике моделирования угроз ФСТЭК, так как к концу первого квартала у вас запланировано согласование этого документа с регулятором. И вот вы составили предварительный перечень угроз, среди которых у вас есть, например, УБИ.175 (фишинг). Я оставлю в стороне, что это описание неполное, так как исходит из того, что фишинг, это угроза только для электронной почты, в то время как фишинг может быть реализован и через блоги, и соцсети, и телефон, и SMS/MMS, и мессенджеры, и т.п. Вариантов может быть очень много, но суть не в этом.

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

Почему я написал "почти"? Дело в том, что, например, та же УБИ.40 (угроза конфликта юрисдикций разных стран) или УБИ.055 (угроза незащищенного администрирования облачных услуг) вообще выбиваются из общей картины и их сложно сравнивать не только с фишингом, но и, например, с УБИ.039 (угроза исчерпания запаса ключей, необходимых для обновления BIOS). Это, кстати, одна из проблем БДУ. В нее включены совершенно разные угрозы - и те, которые могут быть реализованы внешними нарушителями, и те, которые происходят из-за кривых рук админов. Совершенно разные причины реализации этих угроз и, как следствие, разный инструментарий борьбы с ними.

А еще и включены они в перечень вразнобой, без какой-либо понятной систематизации. Ну вот возьмем угрозу УБИ.041 (угроза межсайтового скриптинга), которая вообще-то угрозой и не является. Это всего лишь некая техника, используемая для компрометации пользовательского компьютера для последующего выполнения той или иной задачи. Но допустим, это угроза. Но как  она могла попасть сразу за УБИ.040, упомянутой выше? А спустя несколько пунктов мы встречаем УБИ.058 (угроза неконтролируемого роста числа виртуальных машин). Но почему только виртуальных машин? А где контейнеры? И кстати, почему это угроза применяется только к облакам, но не к собственным ЦОДам, в которых тоже могут применяться виртуалки? А УБИ.070 (угроза непрерывной модификации облачной инфраструктуры)? Под ней понимается всего лишь внесение уязвимостей с обновляемым ПО. Но только в облаках. А в корпоративной или ведомственной сети? А на промышленной площадке? Какие-то хаотические скачки от реальных угроз, идущих со стороны хакеров, к геополитическим угрозам, а потом снова к техническим угрозам, но на аппаратном уровне, а потом к косякам администрирования... Я так и не смог понять логику в нумерации и боюсь что ее просто нет - угрозы добавляют бессистемно, по мере попадания их в голову разработчиков БДУ. Постепенное наполнение БДУ - это неплохо, но лучше бы, чтобы нумерация угроз подчинялась понятной и четко структурированной таксономии, которой нет. Будь моя воля, я бы поменял там всю нумерацию с одноуровневой на многоуровневую и подчинил ее понятной иерархии и структуре.

Вернемся к kill chain. Если я буду опираться только на БДУ, то она мне дает ответ на вопрос "ЧТО может плохого произойти?". Но для нейтрализации этих угроз этого недостаточно. Повторюсь, мне нужно получить ответ на вопрос "КАК?" В случае с угрозами злоумышленников правильно было бы провести декомпозицию и разбить их (угрозы, а не злоумышленников) на этапы, которые можно будет затем привязать к тактикам и техникам, используемым злоумышленниками.

Тактика отвечает на вопрос "ЗАЧЕМ это нужно злоумышленнику". Например, он хочет получить доступ к системе или обойти механизм защиты или установить канал управления или скрыть свою активность или повысить привилегии и т.п. Техника же позволяет ответить на вопрос "КАК это может сделать злоумышленник". Пытливый читатель уже понял, что упоминая техники и тактики, я имею ввиду матрицу MITRE ATT&CK, которая как раз и позволяет приземлить высокоуровневые угрозы к реально применяемым на практике действиям плохих парней.

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

Модель MITRE ATT&CK позволит нам не только говорить о конкретных действиях, с помощью которых злоумышленники реализуют свои угрозы, но и понять, откуда мы будем брать данные для обнаружения соответствующей угрозы. Возьмем, к примеру, уже упомянутую угрозу УБИ.175 (фишинг). В ее описании в БДУ написано, что ее источником является внешний нарушитель с низким потенциалом (а фишинг бывает и внутренний, кстати), а объектом воздействия является рабочая станция, сетевое ПО и сетевой трафик. Вроде и русским языком написано, а нифига непонятно, как это применить в реальной жизни. В NITRE ATT&CK описание этой техники (именно техники, а не угрозы) более практично - указаны:

• источники данных (сетевой трафик, прокси, почтовые шлюзы, почтовые сервера, записи DNS, результаты инспекции TLS/SSL и т.п.)
• использующие эту технику хакерские группировки (полезно для атрибуции и понимания других атак, используемых этой же группировкой)
• защитные меры (учитывая, что под фишингом MITRE также понимает только атаку на уровне e-mail, то список защитных мер очень слабенький, - я бы расширил его)
• методы обнаружения.

Если бы в БДУ можно было бы добавить либо ссылки на MITRE ATT&CK, либо переписать матрицу своими словами, то практическая пользу от БДУ возросла бы на пару порядков (и не забыть систематизировать названия угроз). И нельзя сказать, что ФСТЭК не использует ATT&CK в своей работе и не соотносит угрозы из БДУ с ATT&CK. Вот, например, слайд из презентации авторов БДУ.

Но вот в БДУ пока таких отсылок не появилось, чего не хватает :-( Кстати, о систематизации в той же матрице MITRE. У нее есть вполне понятная модель, согласно которой авторы и развивают ее.

Есть и чуть более сложная таксономия этих элементов:

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

Долгожданное письмо ФСТЭК про Windows 7

Во вторник ФСТЭК выпустила информационное сообщение о ситуации с Windows 7 и Windows Server 2008 R2, чья поддержка закончилась 14 января 2020 года. Если тезисно, то письмо ФСТЭК содержит следующее:

• Microsoft прекратила поддержку и выпуск обновлений для Windows 7 и Windows Server 2008 R2.
• В ФОИВ, ОГВ, ОМС и других используется много сертифицированных копий данных ОС.
• ФСТЭК выдала 7 сертификатов соответствия на данные ОС.
• Обязательное условие действие сертификатов - установка сертифицированных обновлений.
• Отсутствие обновления может привести к росту угроз использования новых уязвимостей.
• ФСТЭК прекращает действие двух сертификатов (видимо с 20-го января 2020 года) и исключает все семь сертификатов из реестра сертифицированных средств защиты с 1-го июня.
• ФСТЭК рекомендует перейти до 1-го июня 2020 года на сертифицированные и обновляемые ОС.
• До перехода надо выполнять рекомендации ФСТЭК из информационного письма.

Замена на новую ОС имеет смысл только на ОС, у которой срок окончания сертификата заканчивается не в 2020-м и даже не в 2021-м году. Сколько ОС у нас сертифицировано по новым требованиям ФСТЭК к ОС, удовлетворяющих таким требованиям? Мобильную ОС Sailfisf, дистрибутив ФССП и EMIAS мы отбрасываем и получаем в итоге следующий список:

• РЕД ОС
• РОСА КОБАЛЬТ
• SUSE Linux Enterprise Server 12 SP3
• Альт 8 СП.

И вот тут у меня закономерный вопрос; даже два. В условиях цикла бюджетирования в госорганах перейти на новую ОС до 1-го июня невозможно. Но это мелочи. Как пишет ФСТЭК - под Windows 7 и Windows Server 2008 R2 написано много разного прикладного софта. Как его до 1-го июня портировать под упомянутые выше форки Linux? Понятно, что это не проблема ФСТЭК и организациям надо было думать раньше, но все-таки проблема существует и как ее решать, непонятно.

 

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

Но самое интересное кроется в аннулировании сертификатов. Основание для этого вроде бы следует из нормативных документов ФСТЭК - нет обновления, сертификат прекращает свое действие. Но парадокс в том, что Microsoft не прекращала выпуск обновлений, устраняющих уязвимости в Windows 7 и Windows Server 2008 R2. Да, домашним пользователям стоит подумать о смене ОС. Но вот корпоративным пользователям Microsoft предлагает EUS - Extended Security Updates, то есть расширенную поддержку, которая действует до января 2023-го года, в течение которой пользователи будут получать обновления, устраняющие уязвимости.

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

10 способов убить свою карьеру в ИБ

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

Большинство CISO считают, что инциденты ИБ не приведут к их увольнению. Только 6.8% CISO считают, что крупная утечка или иная проблема с ИБ могут повлечь за собой разрыв трудового договора. 21,7% считает, что инцидент может стать причиной только выговора, а 56% и вовсе думает, что руководство компании поможет им решить возникшие из-за инцидента проблемы. С другой стороны 55% CISO работает в своей должности менее 3-х лет, а еще 30% - менее двух лет. По оценкам экспертов, многие руководители ИБ покидают свои компании на хороших условиях, с "золотым парашютом". Но немалое количество руководителей кибербезопасности действительно покидают свои насиженные места по причинам, далеким от инцидентов ИБ. Можно выделить 10 таких причин:

1. Неумение говорить с руководством на бизнес-языке. Коль скоро тема ИБ все чаще ложится в повестку дня советов директоров и исполнительных органов компании, то руководство ожидает от CISO умения донести понятным языком сильные и слабые стороны политики ИБ и как они укладываются в общую стратегию бизнеса. Многие CISO попадают на свои позиции благодаря своим техническим навыкам и это приводит к тому, что через какое-то время бизнес разочаровывается в своих ставленниках и отправляет их в отставку, пытаясь найти им более бизнес-ориентированных безопасников.
2. Маскировка проблем. Многие CISO показывают своему руководству только положительные новости, считая, что демонстрация негатива приводит к их негативной оценке со сторону топ-менеджмента. Они не хотят выглядеть некомпетентными и поэтому скрывают все плохое. Кто-то считает, что излишние технические детали только мешают руководству разбираться в ИБ и поэтому почти ничего не рассказывают на управляющих комитетах, что в итоге играет плохую шутку с CISO. Если последний не может быть честным и открытым перед руководством, то доверие к нему падает, а за ним грядет и увольнение. Проблемы есть у всех. Грамотный CISO отличается от своего "шапкозакидательного" коллеги тем, что не только признает негативные стороны в своей работе, но и имеет план по устранению проблем и улучшению ситуации.
3. Сюрприз для руководителя. Никто не любит сюрпризов и никто не хочет попасть впросак из-за инцидента, о котором CISO не предупредил своего босса, и который (инцидент, а не босс) требует крупных и незапланированных затрат на восстановление. Гораздо хуже, если топ-менеджмент узнает об инциденте не от своего руководителя, а из СМИ или от коллег на каком-либо публичном мероприятии.
4. Остаться в одиночестве. Нередко бывает так, что руководство не хочет замечать бревна в своем глазу и признавать, что у них есть проблемы в ИБ, о которых говорит честный CISO. Это может привести к тому, что CISO останется в одиночестве и ему придется выбирать - остаться честным перед самим собой, честно рассказать о проблемах и их последствиях и, возможно, уйти из компании, в которой не любят "правдолюбов", говорящих о проблемах, или дуть в общую дуду "у нас все хорошо, у нас нет проблем", как это делают другие руководители подразделений, вешающих лапшу руководителю, который и рад ловиться на эту удочку.
5. Человек "нет". Нередко безопасники дуют на воду и ставят палки в колеса всем новым и, якобы, небезопасным бизнес-инициативам. Вместо того, чтобы вместе с инициаторами разработать план снижения рисков при внедрении новой идеи или проекта, они просто говорят им "нет". Один раз "нет", второй, третий... И вот "нет" уже говорят самому CISO, когда он заводит разговор о росте своей зарплаты или соцпакета или численности сотрудников и бюджетов. А потом "нет" слышит и сам CISO на вопрос о том, есть ли у него перспективы в компании. Надо уметь двигаться вместе с бизнесом, а не тянуть его на дно своими опасениями, что "мы все умрем".
6. Пропуск чего-то важного. Да, возможно вас не уволят из-за крупного инцидента. Но если вы допустили серьезную дыру в процессах приобретенной компании или недооценили риски в своем предприятии или незаметили тенденций в области угроз, которые нанесли вам ущерб, то у руководства может возникнуть недоверие к вам и вашей способности учитывать интересы бизнеса, а это первый шаг к увольнению.
7. Забывчивость о конкурентах. Руководство имеет возможности оценивать то, что происходит у конкурентов, если не с точки зрения бюджетов и ресурсов на ИБ, то с точки зрения потерь от каких-либо инцидентов. Вас могут уволить за то, что ваша компания потеряла больше, чем ваши конкуренты, которые тоже пострадали от той же проблемы, но пострадали меньше.
8. Падающий парень. Если CISO берут на позицию, которая на несколько уровней ниже других руководителей со схожим кругом обязанностей и ответственности, то дни такого безопасника сочтены. Скорее всего его берут для того, чтобы повесить на него всех собак и потом с "почестями" уволить, если что-то пошло не так. В зависимости от того, где в иерархии находится CISO, зависит то, является ли ИБ для компании фактором развития или центром затрат.
9. Нелюбящий пролетариат. В оригинале идея звучит немного не так, но в том варианте, как мне кажется, для России это неактуальная проблема. По мнению автора, если CISO в своем команде не толерантен к расовым, этническим, половым или иным меньшинствам, то высока вероятность, что руководство компании не будет мириться с таким низким уровнем культуры в подразделении ИБ и сменит главного безопасника.
10. Некомандный игрок. Нельзя все делать в одиночку. Те, кто это пробует делать, не только будут перегружены работой, но и демонстрирует неспособность делегировать задачи, что ставит компанию под угрозу. Если CISO не окружает себя умными специалистами, которые знают, как поступать правильно без подсказки сверху, то у таких CISO не получится выстроить эффективную службу ИБ и они будут обречены на провал. CISO должен уметь нанимать нужных людей и иметь возможность это делать. Если руководство дает карт-бланш главному безопаснику, но не дает ему ресурсов, то дни такого безопасника сочтены - он просто не сможет ничего сделать в одиночку. Первоклассная команда не только способна решать самые сложные задачи, но и показывает, что CISO относится к касте высших руководителей, а не прозябает в условиях нехватки ресурсов со студентами, которые "пороха не нюхали".

7 сценариев, когда в организации используются 2 разных SIEM

В чатике про SOCи зашла тут дискуссия на тему, может ли, и если да, то зачем, использовать SOC два разных SIEM (именно SIEM, а не SIEM и LM или SIEM и UEBA). Вынесу я эту тему в блог, чтобы не забылась она и не затерялась. Я сталкивался с такими ситуациями не раз и поэтому не могу назвать это изначально неправильной идеей. Есть несколько сценариев, когда такая схема возможна:

1. SIEMы для работы и в рамках импортозамещения. На Западе этот сценарий встретить невозможно (разве, что в Китае, но это уже Восток), а вот в России он не редкость. Компания долгое время жила на зарубежном SIEM, но ввиду либо ухода Splunk из России, либо требований по импортозамещению (для госорганов и госкомпаний) вынуждена переходить на отечественные продукты. Да, тут речь идет о переходе, но для таких проектов он обычно длится не один год и поэтому в организации сосуществуют два SIEM. Иногда, правда, переход даже не планируется, так как отечественный SIEM работает, мягко говоря, неидеально.  Например, крупная холдинговая структура строит SOC на все часовые пояса по всей России. SOC двухуровневый - региональные мини-SOCи и один главный в центре. На регионы решили поставить отечественный SIEM. Когда его пытались натянуть на центр, оказалось, что по EPS он не тянет от слова совсем и надо либо ставить кластер из SIEM, что дорого, либо ставить другой, более производительный SIEM.
2. SIEM для работы и для compliance. Это частный случай предыдущего кейса, но у него немного иная мотивация. Один SIEM, как правило, зарубежный, используется для реальной работы, а второй, как правило, отечественный, для демонстрации регуляторам при проверках или для сопряжения с ГосСОПКОЙ. В последнем случае до сих пор нет ясности, должны ли средства ГосСОПКИ быть только российского происхождения или нет. С одной стороны, нормативные акты ФСБ говорят, что да. С другой стороны, практика утверждает обратное. Возможно, это явление временное, так как ни ФСБ еще не разработала регламента оценки соответствия средств ГосСОПКИ, ни российские вендоры пока еще не подсуетились с выпуском продуктов под них. В любом случае, видел проекты, где используется Arcsight или QRadar для основного мониторинга, а решение от Positive Technologies использовалось для передачи данных в ГосСОПКУ. 
3. SIEMы от мамы и от поглощенной компании. Ну тут очевидная история.  Купленная компания использует один SIEM, а купившая - второй. У первой достаточно большая автономия и менять шило на мыло она не готова (инвестиции сделаны, люди обучены, плейбуки написаны). Вторая может только в свой план развития включить переход на единый SIEM. Но будет это через несколько лет. А пока надо сосуществовать вместе. При этом речь не идет о том, что эти SIEM независимы - головная компания требует передачи данных из подчиненного SIEM в головной, что можно сделать как на уровне отправки данных об инцидентах, так и в виде отправки определенных или всех событий.
4. SIEMы для себя и для предоставления услуг. У нас в рамках оказания услуг по проектированию SOC, один из задаваемых заказчику вопросов звучит так: "Вы планируете использовать SOC для себя или будете предоставлять на нем услугу внешним заказчикам?" От ответа на него зависит многое - не в части процессов или компетенций специалистов (хотя и они немного отличаются), а в части именно технологического стека. "Для себя" можно сделать "на коленке", не очень красиво, но так чтобы работало. Для внешней аудитории или для демонстрации руководству "на коленке" уже не работает и могут понадобиться немного иные решения. Да и совмещать внутренние и внешние источники и события безопасности в одном решении не совсем разумно. Поэтому снова возникает тема с 2 SIEM, хотя в данном случае она и вырожденная, - управляют ими разные подразделения, обменивающииеся, разве что, общими данными Threat Intelligence.
5. SIEM для корпоративной сети и для АСУ ТП. Нередко АСУ ТП делают изолированными от внешнего мира и даже от корпоративных сетей. Да и за безопасность АСУ ТП может отвечать подразделение, отличное от корпоративной ИБ. Поэтому и SIEM могут быть изначально разные, которые со временем могут начать обмениваться данными между собой для выявления сложных атак, подразумевающих проникновение через корпоративную сеть (как первый этап kill chain).
6. SIEM для корпоративной сети и для облачных сред. Кейс, схожий с предыдущим, но отличающийся тем, что для мониторинга облачных сред Azure, GCP или AWS используются встроенные в облачные платформы SIEM, а корпоративная сеть мониторится "по старинке". Я про эту историю писал большой обзор на Хабре (часть 1 и часть 2).
7. SIEM для базовой аналитики и а-ля SIEM для глубокого анализа (Big Data Security Analytics). Наверное, это не совсем история про два классических SIEM, так как второй компонент больше относится к инструменту анализа, чем к инструменту визуализации событий безопасности. Но все-таки, учитывая, что SIEM используется для сбора данных и их анализа, могу отнести его к ситуации, когда в организации используется два разных решения. Второй SIEM нередко даже пишут сами на базе open source компонентов, закладывая в него богатый инструментарий для глубокой аналитики событий ИБ на базе машинного обучения. Например, в Cisco именно так родился OpenSOC, про который я писал 3 года назад на Хабре.
8. SIEM подороже и подешевле. Учитывая, что SIEM часто лицензируются по EPS и при большом потоке событий цена решения может быть достаточно велика. Поэтому возникает соблазн, когда вы вместо дорогого SIEM берете тот, у которого цена лицензии на EPS обходится дешевле, или тот, у которого вообще схема лицензирования, отличная от EPS.
9. SIEM побыстрее и помедленнее. В зависимости от архитектуры SIEM, использования реляционной или нереляционной базы данных, скорость индексации и поиска событий ИБ может стать ключевым фактором при выборе SIEM. Мы в Cisco в свое время, среди прочего, по этой причине отказались от одного из SIEM и стали писать свой OpenSOC. При этом у нас продолжает использоваться Splunk для работы с краткосрочной аналитикой и для визуализации. А OpenSOC работает с долгосрочными данными, ретроспективой и неструктурированной информацией.

Да, у вас будут сложности при объединении двух разных SIEM в единый комплекс, когда одно из решений выступает в качестве источника событий для другого. Особенно учитывая, что они могут иметь разные форматы данных, разные их схемы. Но при желании такой вариант все-таки возможен. В ряде случаев поток событий будет распараллеливаться между двумя SIEMами. В ряде случаев у вас IRP/SOAR может работать с двумя SIEMами. Все эти варианты непросты в реализации, что повышает вероятность ошибки. Но и отбросить этот вариант тоже не совсем правильно - иногда применение двух SIEM вполне оправдано. В любом случае описанные выше сценарии вполне рабочие, чтобы разговор о двух разных средствах мониторинга событий ИБ можно было рассматривать как глупую шутку или вырожденный кейс.

Но при этом, если уж вы идете по пути двух и более (и такое тоже бывает) SIEM, убедитесь, что они обладают продвинутым API, который позволяет не только делать им запросы друг к другу, но и который поддерживается вашей IRP/SOAR. Тогда интеграция SIEM станет возможной.

В 2017-м году для SOC Forum я сваял много демотиваторов и мемасиков, одним из которых был такой:

И ведь как в воду глядел. Спустя год с лишним предсказание сбылось, правда для другого вендора. Поэтому вопрос про 2 SIEM вполне себе насущный :-)

Метод "пяти почему" в ИБ

Основатель компании Toyota, господин Тойода, постоянно пользовался правилом "пяти почему" или "пять зачем", которое помогало ему добраться до сути многих сложных процессов и разбираться во многих непонятных ситуациях.

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

Спрашиваете себя - почему я хочу сертифицированный МСЭ? Это первое «почему». Отвечаете: потому что так написано в законодательстве. ОК, переходим ко второму «почему». Почему вы думаете, что так написано в законодательстве? Ответ: Потому что все про это говорят и продавцы МСЭ тоже. Третье «почему»: Почему все, включая продавцов, говорят о необходимости сертификации МСЭ? Ответ: Потому что они хотят заработать денег на мне. Четвертое «почему». Почему они хотят заработать денег? Ответ: Потому что по другому их продукция не продается. Пятое «почему». Почему она не продается? Ответ: Потому что их продукция говно менее функциональная и может похвастаться только сертификатом с высоким уровнем соответствия требованиям регулятора. Ну вроде очевидный ответ, но он ни слова не говорит вам, почему именно вам нужен именно сертифицированный МСЭ? Может вас устроит и несертифицированное решение?

Давайте попробуем пройти эту процедуру еще раз. Начнем сразу со второго "почему". Почему вы думаете, что так написано в законодательстве? Ответ: Потому что я верю тем, кто говорит средства защиты должны иметь сертификат. Третье «почему». Почему я им верю на слово? Ответ: Потому что они лучше меня разбираются в законодательстве. Четвертое «почему»: Почему они лучше разбираются? Ответ: Потому что им надо продать мне свою продукцию. Пятое «почему»: Почему она не продается? Ответ: Потому что их продукция говно... Ой, опять тоже самое :-)

Давайте снова запустим метод "пяти почему". Начнем с третьего "почему". Почему я им верю на слово? Ответ: Потому что я сам не разбирался в хитросплетениях нашего сложного законодательства. Четвертое «почему»: Почему я не разбирался в законодательстве? Ответ: Потому что мне не хочется разбираться в скучном законодательстве. Пятое «почему»: Почему мне не хочется разбираться в скучном законодательстве? Ответ: Потому что... вот тут может несколько причин. Мне не хочется спорить с регуляторами. У меня нет юридического образования. У меня нет юристов, которые бы помогли мне. Мне, у меня, я... Последнее "почему" можно сформулировать проще, не прячась за отговорками. Я НЕ ХОЧУ НАПРЯГАТЬСЯ и МНЕ ТАК ПРОЩЕ.

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

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

Обратили внимание, что в зависимости от того, как вы выстроили цепочку из пяти "почему", у вас выявляются разные первопричины? Очень редко когда она одна. Это как корневая система у растения - есть основной, а есть дополнительные и придаточные корни.

Господин Тойода считал, что в ответе на пятое "почему" и кроется первопричина наших (или не наших) поступков и действий, которая на первый взгляд не прослеживается. Именно она отражает то, что мы скрывали сами от себя и что действительно является важным.

Не бывает одинаковых SOCов

Под конец года немного высвободилось времени и можно наконец-то оформить зарисовки, которые у меня накопились по результатам посещения SOC Forum, а также по результатам ряда проектов и предпроектных переговоров, в которых мне довелось участвовать.

Одним из популярных вопросов является такой "Мы решили построить у себя SOC. А что он должен делать?" Или компания имеет SOC (по крайней мере она так считает) и хочет сравнить себя с другими SOCами на рынке. Обе этих темы, особенно первая, говорит о двух вещах. Во-первых, сегодня нет устоявшегося определения, что же такое Security Operations Center? Даже по-крупному, можно выделить три ключевых направления, каждое из которых может называться модным термином SOC:

• Группа реагирования на инциденты (CSIRT). Основное предназначение такого подразделение - бороться с инцидентами и мониторинг только способствует решению этой задачи. Но его может и не быть вовсе внутри CSIRT или он может быть вынесен за пределы CSIRT, например, в ИТ. Схожая схема уже много лет реализована в Cisco и при правильно выстроенных процессах и взаимодействии между ИТ и ИБ является вполне работоспособной.
• Центр мониторинга ИБ. Это, можно так назвать, классическое понимание SOC, в ядре которого размещается SIEM и который, получая сигналы тревоги от кучи источников, запускает процессы обогащения этих данных и реагирования на инциденты, если они подтверждаются.
• Центр управления кибербезопасностью. Этот вариант реализуется в компаниях, в которых давно и успешно для компании выстроены процессы ИБ, но они достаточно монолитны и их сложно разделять. В таком сценарии мониторинг ИБ или реагирование на инциденты сложно отделить от управления средствами защиты - все делается всеми. 
• Центр поддержки ИБ. Это вольная трактовка аббревиатуры CDC, Cyber Defense Center, которая означает создание государственного центра ИБ, основная задача которого собирать данные об инцидентах и на их основе формировать рекомендации по борьбе с ними. Это некий аналог наших ФинЦЕРТ или ГосСОПКИ.

А все потому, что SOC строится исходя из разных предпосылок и задач. Даже на технологическом уровне, от того, с какими типами источников вы работаете, будет зависеть, будут похожи SOCи между собой или нет. Но SOC - это не только связка SIEM, SOAR и TIP, как трех основных платформ (их на самом деле чуть больше, но NTA, UEBA, EDR, находятся на стыке источников данных и платформ мониторинга). Это еще и сервисная стратегия, которой мало уделяют внимания при строительстве SOC, но которая и определяет каким он в итоге будет. Без нее SOC строится "снизу вверх", от технологического стека к набору процессов и поддерживающих их playbook.

С сервисной стратегией мы строим SOC "сверху вниз" и отталкиваемся от того, что нужно бизнесу в части мониторинга. Но про это я уже отдельно писал. Но даже если вернуться к более распространенной модели построения SOC "снизу вверх", даже в этом случае могут быть реализованы совершенно различные сервисы, которые повлияют и на упомянутый вначале заметки вопрос.

Вы только мониторите события безопасности, полученные из разнородных источников, или еще проводите активный Threat Hunting? Вы потребляете или создает контент Threat Intelligence? Вы "делаете SOC" для себя или помогаете внешним организациям? Red Team и фишинговые симуляции являются частью вашего SOC? Достаточно посмотреть на эти 4 вопроса (а их можно задать гораздо больше), чтобы понять, что сервисный каталог SOC, а значит и он сам, будет отличаться от организации к организации. Даже при его совпадении у вас начнутся отличия в сервисной модели (что-то вы будете делать самостоятельно, а что-то отдадите на аутсорсинг), а также на уровне технологического стека и компетенций аналитиков.

Отсюда простой вывод, который подтверждается практикой построения и аудита SOCов в Cisco, - двух одинаковых SOCов не бывает. Поэтому и не бывает универсального ответа на вопрос "Что такое SOC?". Поэтому так важно уметь сначала договориться о терминах, а уже потом спорить :-)

Является ли ГОСТ по ИБ обязательным к применению?

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

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

Правительство в стороне не осталось и спустя полтора года с момента принятия ФЗ-162 выпустило свое Постановление под номером 1567 (оно отменило ранее действующее ПП-822 на ту же тему), которое утвердило два положения:

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

"Нашу" тему затрагивает второе положение. Оно очень короткое - в нем всего 10 пунктов (по сравнению с полусотней в положении о стандартизации оборонной продукции".

Согласно нему стандартизацией ИБ у нас занимаются ФСТЭК, ФСБ, МинОбороны и СВР, а утверждает разработанные ими стандарты Росстандарт. ЦБ в списке нет.

Предметом стандартизации этих ГОСТов (в том числе и ограниченного распространения) является продукция и связанные с ней процессы. Предметом регулирования ГОСТ 57580.1 является не продукция и не процессы, а уровни и требования.

Отсюда возникает закономерный вопрос - на каком основании ГОСТ Р 57580.1 считается обязательным? В самом стандарте написано, что область его применения устанавливается в нормативных актах Банка России путем включения в них ссылки на ГОСТ, что разрешено 27-й статьей закона "О стандартизации в Российской Федерации". Ни слова про то, что ГОСТ в этом случае является обязательным. Так является ли он таковым?

Стоит обратиться к другим нормативным правовым актам. В частности к Положению Банка России от 22.09.2017 №602-П "О правилах подготовки нормативных актов Банка России", в котором перечисляются нормативные и ненормативные акты Банка России:

Национальных стандартов в их числе нет. При этом любые обязательные нормативные и нормативные правовые акты, включая и документы ЦБ, которые устанавливают обязательные требования к своим "подопечным" должны быть официально зарегистрированы в МинЮсте. Это вытекает из 1009-го Постановления Правительства.

Разумеется, не все нормативные акты ЦБ подлежат регистрации. Но согласно 602-П список нерегистрируемых документов четко определен и ГОСТы к их числу не относятся.

Согласно же разъяснениям МинЮста, утвержденным приказом от 04.05.2007 №88, национальные стандарты можно не регистрировать, но только если они не содержат нормативных предписаний. Поэтому получается, что если рассматривать ГОСТ 57580.1 как содержащий такие предписания, то он должен быть зарегистрирован МинЮстом, а это условие выполнено не было и, как следствие, применению этот ГОСТ не подлежит. Если же рассматривать ГОСТ просто как сборник рекомендаций, то тогда все нормально - это руководство к действию, но не более. Обязать его исполнять и тем более наказывать за его неисполнение нельзя.

Ну и еще. Вспоминая законы "О Центральном банке" и "О Национальной платежной системе", Банк России имеет право устанавливать обязательные требования по защите информации, но только по согласованию с ФСБ и ФСТЭК. Согласно уже упомянутому Положению Банка России 602-П, нормативный правовой акт считается совместно изданным, если он подписан/утвержден руководителями соответствующих ФОИВ, то есть в нашем случае с ФСТЭК и ФСБ.  Те же 382-П, 683-П, 684-П были согласованы с указанными регуляторами по ИБ. И соответствующий гриф согласования должен быть на совместно принятом нормативном правовом акте. А вот ГОСТ 57580.1 это требования снова нарушает - никаких согласующих грифов на нем нет.

Не буду делать финальных выводов по обязательности принятого Банком России ГОСТа для финансовых организаций. Это пусть банковские юристы об этом думают. Но на мой взгляд, обязательными ГОСТы бывают только в случае их разработки Министерством Обороны, Федеральной службой безопасности, Службой внешней разведки и Федеральной службой по техническому и экспортному контролю. В остальных случаях увы...

Как стать SOC-аналитиком?

Коллеги из Ангары, которая отмечает 5 лет своего существования на российском рынке ИБ, опубликовали заметку о том, как стать SOC-аналитиком и какими навыками и компетенциями должен обладать аналитик SOC. На первое место они поставили знание законодательства по ИБ. Я в корне не согласен с такой постановкой вопроса, так как считаю, что аналитикам SOC вообще не нужно знание законодательства, которое никак не помогает в работе по обнаружению инцидентов ИБ. Но на самом деле статья Ангары заставила меня задуматься, а какими знаниями и навыками должен обладать аналитик SOC?

С точки зрения необходимых знаний, я бы выделил следующие:

• знание сетевых протоколов и принципов построения сетей, в том числе беспроводных, мобильных, телефонных, Интернет, спутниковых (при необходимости)
• знание принципов и протоколов сетевой адресации и маршрутизации, а также особенностей влияния локального и глобального сетевого оборудования на них
• знание основного сетевого оборудования, его архитектуры и особенностей его конфигурирования и администрирования, механизмов сбора и регистрации событий, а также анализа
• знание основных СУБД, их архитектуры и особенностей их конфигурирования и администрирования, механизмов сбора и регистрации событий, а также анализа
• знание основных типов ПК, их архитектуры и особенностей их конфигурирования и администрирования, механизмов сбора и регистрации событий, а также особенностей подключения периферийных устройств, а также анализа
• знание основ виртуализации, контейнеризации, терминального доступа, их архитектуры и особенностей их конфигурирования и администрирования, механизмов сбора и регистрации событий, а также анализа
• знание основ основных ОС (Windows, Linux, MacOS, Android, iOS), их архитектуры и особенностей их конфигурирования и администрирования, механизмов сбора и регистрации событий, а также анализа
• знание основ сетевой и системной безопасности (МСЭ, IDS, WAF, антивирус, IDM, обманные системы, песочницы и т.п.)
• знание угроз и уязвимостей, реализуемых на разных уровнях - сетевом, системном, прикладном
• знание типов атак (DDoS, подбор пароля, сканирование, подмена, перехват, переполнение буфера, скрытые каналы, CSS, PL/SQL Injection, вредоносный код и т.п.)
• понимание последствий от реализации угроз
• знание принципов и протоколов web, включая web-почту, web-сайты, CMS, cookie, а также инструментов их анализа
• знание принципов и протоколов построения e-mail, а также инструментов ее анализа
• знание принципов и протоколов построения инфраструктуры DNS, а также инструментов ее анализа
• знание принципов и протоколов построения IP-телефонии, мессенджеров, VPN и т.п., а также инструментов их анализа
• знание принципов сбора информации, управления этим процессом, его возможностей и ограничений
• знание принципов расследования инцидентов
• знание принципов сбора доказательств и обеспечения их сохранности
• знание основ и методов обнаружения атак на уровне сети и хостов
• знание концепции Kill Chain и методов, используемых злоумышленниками (TTP)
• знание способов обхода средств защиты (evasion)
• знание методов сбора и анализа метаданных (e-mail, http, netflow и т.п.)
• знание основных протоколов и форматов регистрации событий безопасности (например, syslog)
• знание основных SIEM, их архитектуры и особенностей их конфигурирования, механизмов сбора и регистрации событий, а также анализа
• знание основ/стандартов написания правил обнаружения атак и корреляции событий, а также индикаторов компрометации
• знание основ визуализации собранной информации и формирования отчетов
• знание признаков физического и психологического поведения, характеризующего аномальную или подозрительную активность

К необходимым навыкам я бы отнес:

• умение писать простые скрипты для автоматизации рутинных задач
• умение писать сигнатуры и правила для обнаружения атак и инцидентов (например, Yara, SIGMA, Snort и т.п.)
• умение анализировать сетевой трафик
• умение анализировать журналы регистрации событий ОС, сетевого оборудования, СУБД, приложений и т.п.
• умение захватывать сетевой трафик и вычленять из него важную информацию
• умение подключать удаленные источники событий
• умение работать с индикаторами компрометации и OSINT
• умение идентифицировать, локализовывать и отслеживать устройства в инфраструктуре 
• умение выявлять пробелы в собранной информации и формулировать требования по их устранению
• умение интерпретировать собранные данные, выявлять атаки и уязвимости, аномальную активность
• умение работать с SIEM, IRP/SOAR, TIP, NTA, EDR, UEBA, CASB, песочница
• умение работать с системами представления результатов анализа и генерации отчетов
• presentation skills
• writing skills (а фиг знает, как это емко сформулировать)
• умение принимать решения
• soft skills
• критическое мышление

Вообще в статье Ангары есть некоторая недосказанность, так как не совсем понятно, под "аналитиком SOC" понимается специалист 1-ой, 2-ой или 3-ей линий, или любой специалист SOC, включая аналитиков Threat Intelligence, специалистов по реагированию на инциденты, специалистов по форензике и другие роли в SOC. Даже если речь идет о L1-L3, то в зависимости от линии, наполнение ролей и, как следствие, требуемые навыки и знания, будут разными. Но, думаю, основные моменты я все-таки учел. 

Новости ИБ за новогодние праздники

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

• Убийство официального лица Ирана, генерала Сулеймани, привело к тому, что американское агенство по информационной безопасности выпустило предупреждение о возможных геополитических кибератаках, особенно со стороны Ирана, который пообещал 13 катастрофических сценариев ответных действий на агрессию со стороны США (и уже искал экспертов для атак на критическую инфраструктуру США). Это уже привело к тому, что отдельные штаты начали отчитываться о том, что они фиксируют десятки тысяч кибератак со стороны Ирана (хотя в реальности они фиксируют всего лишь сканирования портов). Но, думаю, мы еще увидим последствия этой эскалации в киберпространстве.
• ФБР снова просит Apple разблокировать iPhone двух обвиняемых в незаконной стрельбе.
• Dell ищет покупателя на подразделение RSA Security, а также конференцию RSA Conference.
• Конгресс подготовил отчет, который должен быть представлен в марте-апреле и реализация мероприятий которого должно повысить уровень защищенности частных американских компаний. Интересно, что они, по слухам, хотят чуть ли не вписать правило "1-10-60" как рекомендацию по ИБ.
• Accenture покупает бизнес услуг ИБ Symantec, включая и 6 SOCов, разбросанных по всему миру. Вообще Accenture за последние несколько лет скупил уже с полдесятка ИБ-стартапов,  желая стать серьезным игроком этого рынка.
• Исследователи смогли реализовать новую, более эффективную и практичную атаку на SHA-1.
• Было несколько успешных атак шифровальщиков, заставивших жертв выплатить выкуп, кииберпреступникам. Но мне запомнился один кейс с одной из фирм США, занимающейся телемаркетингом. После неудачного восстановления от последствий шифровальщика, за день до Рождества, 300 сотрудников компании получили письмо от генерального директора о том, что они могут искать новую работу, так как компания не смогла восстановиться после кибератаки.
• MITRE выпустила новую матрицу техник, тактик и процедур злоумышленников - на этот раз для промышленных систем. Это первая версия, которая готовилась более двух лет, но которая продолжает наполняться новыми TTP.