Архив метки: opensource

Закладка в прошивке светодиодной гирлянды

Закладка в прошивке светодиодной гирлянды

Закладка в прошивке светодиодной гирлянды. Некоторые любители прекрасного любят выставлять у себя из окна светодиодные DIY-гирлянды, на которых можно отображать разнообразные эффекты и надписи. Довольно эффектная штука. Но оказалось, что в прошивке для популярного проекта такой гирлянды была закладка. В полночь 1 января поверх всех эффектов начал отображаться запрещённый в России лозунг. На хозяев одной из украшенных квартир составили протокол о дискредитации ВС РФ.

Как закладка попала в код? Автор проекта пишет на форуме "я не являюсь автором данной прошивки". 🤷‍♂️ Настоящим автором прошивки является человек из сопредельного враждебного государства. Код на наличие закладок толком не проверяли. 🤦‍♂️

Это к слову о контроле над open source кодом и принципе "тысячи глаз". Используя open source код, за которым НЕ стоит внушающая доверие репутация организации или человека, задавайте себе вопрос "а что будет, если туда всё-таки заложили что-то зловредное?"

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

Три установки после исхода западных вендоров. Предыдущий пост про судьбу специалиста был, разумеется, и про меня тоже. Мне было вполне комфортно работать с западными VM-решениями и писать об этом в своём бложике. Не могу сказать, что исход западных вендоров меня порадовал. Но, с другой стороны, я не был ультрасфокусированным специалистом по Qualys, Tenable и Microsoft Defender, поэтому какой-то катастрофой для меня это не стало. Но заставило призадуматься. В итоге я сформулировал для себя 3 установки, которые выглядят полезными в сложившихся условиях. Возможно они кому-то ещё придутся по вкусу.

1. Специализироваться не на конкретных технических решениях от конкретных вендоров, а на проблеме в целом. Как можно лучше понимать что именно происходит под капотом решений и как, при необходимости, обходиться без них. В контексте нашей темы - как происходит детект уязвимостей в каждой из систем, какие есть тонкости, что и как можно было бы улучшить. Вендоры приходят и уходят, а проблемы остаются.

2. Фокусироваться на Open Source проектах, в особенности на GNU/Linux. Здесь есть несколько моментов:

2.1. Мы во многом утратили или утратим в ближайшем будущем доступ к проприетарным западным решениям. Но вот доступ к Open Source останется, этого у нас никто не отберёт. Несмотря на попытки ограничить возможности контрибьютить код и вести свои проекты, эффективных механизмов препятствовать этому также нет. Поэтому для российского специалиста активная самореализация в Open Source проектах это логичный путь для приобретения скиллов актуальных в общемировом масштабе.

2.2. Open Source это основа российского импортозамещения. Практически все российские ОС это Linux, отечественных IT/ИБ продуктов без использования открытых библиотек также не бывает. Можно долго спорить на тему оправдано ли называть отечественным то, что в основном разрабатывается где-то в Калифорнии. Имхо, это довольно скверно, но может быть в какой-то степени скомпенсировано вовлечённостью в эти проекты российских специалистов как со стороны разработки, так и со стороны использования. Безусловно история успеха здесь проект PostgreSQL. Если появятся эффективные центры компетенций по ключевым открытым компонентам, то возможно появятся и шансы "перевернуть игру", и уже в США будут переживать по поводу российская влияния на Open Source. А если не появятся, хотя бы несколько снизим свои риски в процессе. 😉

3. Относиться к российским коммерческим решениям с "презумпцией крутости". Если не доказано, что продукт полностью неработоспособен и это явное мошенничество, считать российский продукт крутым. 🙂 Я не согласен с бесконечной критикой российских продуктов, что они стоят дороже и при этом менее функциональны. Вернее да, это так, они действительно часто дороже и менее функциональны. 😅 Но критиковать их за это также бессмысленно как возмущаться тем, что за летом приходит зима. Здесь сошлюсь на уморительный пост Рустэма Хайретдинова про первое свидание и сальто назад на коньках. 😆 Наши вендоры зачастую стартуют с нуля, имея в сотни и тысячи раз меньше ресурсов, чем западные. У них нет возможности демпинговать и работать на перспективу, им нужно выживать и развиваться здесь и сейчас. И при этом они умудряются производить что-то сопоставимое с западными решениями. Это ли не чудо! В целом, считаю, что нам к российским ИБ-вендорам, особенно к стартапам, нужно относиться как в Израиле относятся к своим. Холить, лелеять, гордиться, нахваливать и оказывать всяческое содействие. Ну возможно делать это чуть менее энергично, все же у нас несколько иная стилистика. Но ни в коем случае не хаить их за то, что они не top-notch за копейки.

Зарелизил на неделе утилитку imgtov, с помощью которой свои видяшки собираю, как и обещал ранее

Зарелизил на неделе утилитку imgtov, с помощью которой свои видяшки собираю, как и обещал ранее. Последнюю видяшку собрал аж в 8k качестве, вроде норм на Youtube и VK залилось.

Название это абберевиатура от "images to video". Кроме того "tov" это "хорошо" на иврите ("טוב"). И это хорошо. 🙂

Сделал максимально примитивно. В input.txt кладем таймстемпы. Исходные файлы с картинками кладем в директорию images. В корень кладем input.mp3. Запускаем imgtov.py. Получаем video.mp4, радуемся. Подробнее читайте в описании проекта на гите.

Если вдруг кому-то ещё такое надо, пользуйтесь!

У Алексея Лукацкого сегодня был интересный пост про "H.R.7900 - National Defense Authorization Act for Fiscal Year 2023"

У Алексея Лукацкого сегодня был интересный пост про "H.R.7900 - National Defense Authorization Act for Fiscal Year 2023". Длиннющий документ. Местами видимо интересный. Если в PDF выгружать, то там 3854 страницы. Слово "Russia" там встречается 281 раз. Солидно. 🙂 "China" только 130 раз.

Алексей Викторович обратил внимание, что теперь согласно "SEC. 6722. DHS SOFTWARE SUPPLY CHAIN RISK MANAGEMENT." контракторам Department of Homeland Security (DHS) придется собирать зависимости их продуктов в "bill of materials" и доказывать сертификатом, что ни в одной из зависимостей нет ни одной уязвимости из NVD. Не то, что там критичных уязвимостей нет, а вообще никаких CVE нет!

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

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

Но меня больше зацепило, что там речь идет не только об NVD, но и

"(B) any database designated by the Under Secretary, in coordination with the Director of the Cybersecurity and Infrastructure Security Agency, that tracks security vulnerabilities and defects in open source or third-party developed software."

Это что такое? Это просто вставочка на будущее, типа вдруг когда-нибудь сделают ещё какую-нибудь базу? Или есть какая-то ещё база уязвимостей Open Source софта разработанная DHS и CISA, которая не в паблике? Загадочно. 🙂

PS: Надо бы тамошним законодателям рассказать, что у каждого item в "bill of materials" могут быть свои зависимости, и в этих зависимостях могут быть (и есть) уязвимости, а для самого item-а в NVD об этом никакой информации не будет. Как не было отдельной CVE под каждый софт уязвимый Log4Shell. Даешь "bill of materials" для каждого item-а и тотальный разбор этой адской матрешки! Муа-ха-ха! 😈