Архив за месяц: Ноябрь 2022

Что Наталья Касперская говорила на SOC форуме про кибервойну и децифровизацию (1/2)

Добавить комментарий

Что Наталья Касперская говорила на SOC форуме про кибервойну и децифровизацию (1/2).

На прошлой неделе вышло несколько довольно резонансных новостных статей по мотивам выступления Натальи Ивановны Касперской на SOC форуме. Пока видео с выступления не было, комментировать было сложновато. Но теперь видео есть, каждый может посмотреть пленарку и сделать выводы. По мне как и в прошлом случае с "отключением смартфонов" прямая речь оказалась более чем адекватной, а журналисты опять всё передернули и переврали. Не поленился выписать, что конкретно было сказано.

Про кибервойну

[Вступление про 9 месяцев кибервойны]
[Игорь Ляпунов: технологический суверенитет, импортозамещение и технологический рывок как-то не сочетаются.]

"Я начну все-таки с кибервойны. Здесь прозвучал термин "кибервойна", "идет кибервойна". Я не согласна, что идет кибервойна. Главная недружественная страна кибервойну против России не разворачивала, потому что если бы она её развернула у нас бы всё уже выключено было. У нас бы все ключевые элементы инфраструктуры просто бы перестали работать. Товарищи, давайте не будем строить себе иллюзий. Базовые станции мобильных операторов, основные системы управления технологическими процессами, контроллеры на ключевых наших сетях, это все импортное у нас. Большинство из них с удаленным управлением. Выключить не представляет никакой сложности, никаких атак не нужно. Атаки делают […] переобувшиеся на политическую борьбу хакеры-самоучки. Профессионалы, профессиональные спецслужбы, конечно, действовали бы по-другому и гораздо более жестко. И мы, конечно, не готовы к этому.

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

[…] Цифровой суверенитет состоит из двух компонент: электронного и информационного. С этого и надо начинать.

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

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

На сайте SOC форума про записи выступлений пока ни слова, но они уже есть на ютуб-канале Ростелекома

Добавить комментарий

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

SOC-форум 2022 – зал 1 (первый день)
SOC-форум 2022 – зал 2 (первый день)
SOC-форум 2022 – зал 3 (первый день)

SOC-форум 2022 – зал 1 (второй день)
SOC-форум 2022 – зал 2 (второй день)
SOC-форум 2022 – зал 3 (второй день)

Про Pushwoosh

Добавить комментарий

Про Push­woosh. На днях вышла занимательная статья в Рейтерс как новосибирцы сделали успешный бизнес в США и как им его сейчас рушат с криками "ату их, они русские!"

Push­woosh предоставляет SDK для разработчиков, позволяющее им профилировать онлайн-активность пользователей приложений для смартфонов и отправлять индивидуальные push-уведомления с серверов Push­woosh.

В статье утверждается такая схема работы: 40 человек разработки в Новосибирске, продажи через C‑Corp в Делавере зарегистрированную на физика. Адрес в США это частный дом в пригороде Вашингтона, владелец которого, друг гендира Push­woosh, согласился пересылать корреспонденцию. Американские руководители компании это фейки с фотками из стока. В общем, незамороченный фасадик.

После февральских событий попытались отмежеваться от России.

"Push­woosh Inc. заказывала аутсорсинг разработки продукта у компании из Новосибирска, упомянутой в статье. Однако в феврале 2022 года Push­woosh Inc. расторгла контракт".

"Push­woosh хранит свои данные в США и Германии".

Помогло им это? Ну судя по статье нет. Несмотря на то, что "агентство Reuters не обнаружило доказательств того, что Push­woosh неправильно обрабатывал пользовательские данные" одних подозрений, что это "российское ПО" американским компаниям хватило, чтобы рвать контракты. В статье приводится перечень таких компаний.

Какие можно сдать выводы:

1. Даже если вы релоцируетесь сами, релоцируете команду, смените юрлицо, смените имя, сделаете пластическую операцию, завернетесь во флаг чужой страны и будете транслировать 24/7 махровую пропаганду в соцсетях, все равно при желании вам смогут предъявить за ваши "roots" и порушить бизнес. Во всяком случае в США и Европе точно.

2. Если все же хочется работать на таких рискованных, хоть и безусловно очень жирных рынках, то фасады нужно строить основательнее. Регать ООО "Пушвуш" в Новосибирске было опрометчиво, назвали бы хотя бы ООО "ТолкайСвисти". 🙂 В штатах можно было бы и нанять мини-офис для симбурде. А аутсорсинг закамуфлировать под индийский например. Помогло бы это? Совсем не факт, см. п.1, но наезжать стало бы сложнее.

3. Око за око. "Данные, которые собирает Push­woosh, аналогичны данным, которые могут быть собраны Face­book, Google или Ama­zon, но разница в том, что все данные Push­woosh в США отправляются на серверы, контролируемые компанией (Push­woosh) в России". Как кошмарят компании с российскими корнями в Штатах, так же следовало бы кошмарить аналогичные компании с американскими корнями в РФ. Было бы справедливо.

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решение

Добавить комментарий

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решениеПро SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решение

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: на основании чего принимается решение.

В первой части определили, что SSVC это по сути опросник. Задаем значения некоторых параметров связанных с уязвимостью, получаем в результате решение по уязвимости (Track, Track*, Attend, Act).

В документе процесс принятия решения визуализируется в виде дерева по которому мы идем и в итоге получаем итоговое значение. Поэтому "параметры" там именуются как "точки принятия решения" ("deci­sion points"). Типа приходим на такую развилку и решаем куда дальше идти. Кажется никакой смысловой нагрузки это не несет, а только запутывает. Поэтому для меня это будут просто "параметры".

Итак, параметры следующие:

1. (State of) Exploita­tion — (Состояние) Эксплуатации
2. Automat­able — Автоматизируемость
3. Tech­ni­cal Impact — Техническое Воздействие
4. Mis­sion Preva­lence and Pub­lic Well-Being Impact — Целевая Распространенность (понимаю, что так себе перевод, но это хитро вводится, будем разбираться позже) и Воздействие на Общественное Благополучие

Часть из них могут принимать 2 значения, часть 3 значения. Значения "фиг его знает" умышленно нет. Когда выбрать значения сложновато "CISA определяет значение, которое является наиболее разумным предположением, основанным на предыдущих событиях" ("the most rea­son­able assump­tion based on pri­or events"). "Такой подход требует надежных исторических данных, и будущие события могут со временем изменить эти предположения." Что за события и исторические данные имеются ввиду сказать сложно. Подозреваю, что все же имеет место быть традиционный "пол, палец, потолок". Если есть идеи, напишите в комментах.

Всего 36 комбинаций параметров и все они представлены на 10‑й странице SSVC Guide от CISA.
Каждый из этих параметров заслуживает детального рассмотрения и медитации, что я и планирую далее по этой теме делать.

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: решения по уязвимостям

Добавить комментарий

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: решения по уязвимостям.

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

1. Отслеживать (Track). В настоящее время каких-то особых действий по уязвимости не требуется. Организация продолжает отслеживать новую информацию по уязвимости и проводить её переоценку. CISA рекомендуют устранять такие уязвимости в рамках стандартных сроков обновления.

2. Внимательно отслеживать (Track*). Уязвимость содержит определенные характеристики, которые могут потребовать более тщательного мониторинга изменений. CISA рекомендуют устранять такие уязвимости в рамках стандартных сроков обновления.

3. Уделять внимание (Attend). Уязвимость требует внимания со стороны нижнего уровня менеджмента (organization's inter­nal, super­vi­so­ry-lev­el indi­vid­u­als). Необходимые действия могут включать запрос помощи или информации об уязвимости, приводить к публикации внутренних и/или внешних нотификаций об уязвимости. CISA рекомендуют устранять такие уязвимости быстрее стандартных сроков обновления.

4. Действовать (Act). Уязвимость требует внимания со стороны нижнего уровня менеджмента и ТОПов (organization's inter­nal, super­vi­so­ry-lev­el and lead­er­ship-lev­el indi­vid­u­als). Необходимые действия включают запрос помощи или информации об уязвимости, а также публикацию внутренних и/или внешних нотификаций об уязвимости. Как правило, внутренние группы встречаются и договариваются как будут реагировать на эту уязвимость, а затем выполняют согласованные действия. CISA рекомендуют устранять такие уязвимости как можно скорее.

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

Как я понимаю о чем это вообще

Кажется во многих организациях, если не во всех, есть чатики безопасников, куда кидаются уязвимости для обсуждения. И там уже сообща решается вопрос стоит ли подрываться и оперативно фиксить уязвимость, или оно в регулярном процессе само зафиксится. Очевидно какие-то уязвимости не особо критичные и вряд ли будут эксплуатироваться в реальных атаках (множество вариаций Melt­down и Spec­tre например). По каким-то с ходу непонятно, но выглядит подозрительно и надо бы за ними приглядывать (недавняя SQLite RCE CVE-2022–35737). Какие-то очевидно нужно оперативно брать в работу, т.к. явно опасно и в целом понятно как устранять (какая-нибудь очередная RCE в Exchange или AD). А для некоторых уязвимостей нужно на ТОПов выходить, запускать их отдельными треками и патчить пожарном режиме (Log4Shell, MS17-010).

В принципе процесс это знакомый и естественный. Но так сразу и не скажешь по какому принципу в таком чатике принимаются решения по конкретной уязвимости, "экспертная оценка" во всей красе. И цель SSVC, насколько я могу судить, этот процесс несколько формализовать.

В следующей части начнем разбираться на основании чего решение принимается. И т.к. недавняя ФСТЭКовская "Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств" тоже +- про это, хотя и реализация совсем другая, напрашивается некоторое сравнение / размышление как мы до жизни такой дошли. Stay tuned.

Про восстановление внезапно отъехавшего Xiaomi Redmi Note 11 (2/2)

Добавить комментарий

Про восстановление внезапно отъехавшего Xiao­mi Red­mi Note 11 (2/2).

Какие выводы сделал:

1. В сторону Xiao­mi и Qual­com — безусловное фи. Таких массовых сбоев быть не должно, вендор должен это фиксить сам, а не отмалчиваться. Это случилось потому, что китайцы такие китайцы, а с другими вендорами такое произойти не может? Не уверен, но решайте сами.

2. "Devel­op­er options" и "USB debug­ging" с аппрувом на рабочей машине должны быть активированы заранее на всякий случай.

3. Важные файлы должны храниться на sd-карте, тогда их просто будет достать, если телефон окирпичится.

4. Бэкапы? Безусловно это нужно делать каким-то образом.

5. Целиком полагаться на телефон дело такое себе. А если бы на телефоне был электронный билет который нужно было срочно предъявить? А если бы сегодня был не выходной, а надо было активно передвигаться на такси? Есть повод поразмышлять о зависимости от гаджетов и необходимости резервирования.

Про восстановление внезапно отъехавшего Xiaomi Redmi Note 11 (1/2)

Добавить комментарий

Про восстановление внезапно отъехавшего Xiao­mi Red­mi Note 11 (1/2).

И на старуху бывает проруха, как сказала польская красавица Инга Зайонц через месяц после свадьбы с другом моего детства Колей Остен-Бекеном. (с)

Сегодня я проснулся и обнаружил, что мой телефон Xiao­mi Red­mi Note 11 ровно через 11 секунд после разблокировки экрана сваливается в черный экран с крутящимся белым значком загрузки. Через пару минут в таком режиме телефон открывает меню MIUI 5.0 Recov­ery Mode. И так постоянно. Я перепробовал различные варианты загрузки системы (опцией из Recov­ery Mode, по тайм-ауту из Recov­ery Mode, загрузка после полного выключения, после перезагрузки, загрузка в Safe Mode), но ситуация та же — стабильная работа до разблокировки экрана, потом 11 секунд и снова сваливается в черный экран.

Учитывая, что на xda-devel­op­ers есть свежий топик от 5 ноября с описанием ровно такой же проблемы и 7 страницами обсуждения, это массовый сбой, связанный с сервисом com.qualcomm.location.

"We now know the cause of the issue thanks to Red­dit user pxbrz, and a fix (eas­i­er if your phone has USB Debug­ging enabled, if not you'll have to try to enable it as fast as you can before the reboot): One of Qualcomm's process­es for the phone's loca­tion (called com.qualcomm.location) crashed and then reboot­ed itself when it did, but didn't clean up the ram, which made the phone crash by a lack of acces­si­ble mem­o­ry. To fix it, you can use the fol­low­ing com­mands with adb:
adb shell
pm unin­stall ‑k –user 0 com.qualcomm.location
Then it should be fixed (you'll lose loca­tion ser­vices until you update the phone obvi­ous­ly)."

USB debug­ging у меня был выключен. Можно ли включить USB debug­ging за 11 секунд? Я старался и у меня не получилось. Вот что я делал:

Этап 1. Включаем "Devel­op­er options"
1. Разблокируем экран
2. Находим шестеренку с настройками и жмем на неё
3. Жмем на "About Phone"
4. Проворачиваем вниз к "All specs" и заходим
5. Барабаним по MIUI ver­sion пока не получим "You are now a develper"

На это уходит секунд 10, потом отваливаемся в reboot, снова попытка

Этап 2. Включаем "USB debug­ging"
1. Разблокируем экран
2. Находим шестеренку с настройками и жмем на неё
3. Проворачиваем на "Addi­tion­al set­tings" (провернуть до конца, вторая опция сверху) и заходим
4. Проворачиваем на "Devel­op­er options" (провернуть до конца, посередине экрана) и заходим
5. Находим "USB debug­ging" (пролистнуть примерно на второй экран), переводим в ок
6. Проставляем галку в warning‑e "I am aware" и жмем ок …
Ну как жмем, не успеваем нажать, потому что кнопка блокируется warn­ing-ом как раз на 10 секунд. 🤬

Конечно те, кто поставили туда этот ворнинг вряд ли предполагали, что людям может потребоваться включить USB debug­ging очень быстро. Но цензурных слов у меня для них нет.

Здесь я загрустил и пришел к выводу, что придется делать fac­to­ry reset как минимум чтобы включить USB debug­ging. 😔

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

После ресета подключил USB debug­ging и без особых проблем удалил com.qualcomm.location

$ adb shell
spesn:/ $ pm unin­stall ‑k –user 0 com.qualcomm.location
Suc­cess
spesn:/ $

Пока работает. Посмотрим что будет дальше.