Макс Князев @MaxiEnergy
DevOps-инженер, Инженер ИБ
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
System Software Engineer, AppSec-Engineer
Senior
From 300,000 ₽
DevOps
System administration
Network administration
Information Security
Protection of information
DevSecOps
Threat analysis
Web development
Interface development
Programming microcontrollers
Есть) Мне ее ребята из Яндекса даже подарили на Новый год. Сказали, что очень понравилась моя идея с модификацией игрушечного робота-доставщика
Часть профессий вымрет, так как перестанет быть актуальными из-за того, что данная работа будет выполняться значительно быстрее и эффективнее с использованием нейросетей. Это факт. Такое происходило в истории человечества несчетное число раз
А вот бояться этого точно не стоит, потому что:
Повсеместное распространение нейросетей и подобных технологий сможет простимулировать появление новых профессий и видов работ. Пока что сложно сказать, каких конкретно, но, скажем так, с появлением персональных компьютеров появились и те, кто их производит, улучшает, собирает, чинит и тд
Существующие профессии будут пересмотрены. Суть останется, а вот нюансы, навыки и прочее претерпят изменения. К примеру, до изобретения машин извозчики развозили людей на лошадях. Теперь это делают таксисты. В обозримом будущем это будут делать роботакси. И их тоже придется кому-то обслуживать. Суть остается одна, а навыки требуются иные. С программированием так же. Актуальны сейчас навыки работы с теми же перфокартами? А ведь в свое время это была база, без которой вы не смогли бы стать программистом вообще. Суть осталась неизменна, но изменились процессы. Сейчас мы видим то же самое
Перемены всегда пугают. Это нормально. Профессии исчезают. Это тоже нормально. При этом как-то же ведь люди находят себе работу, род деятельности и прочее, опираясь на «дух времени» и существующие возможности
P.S. Мне нравится эта старая открытка, когда люди боялись повсеместной электрификации. Кто-то боялся потерять работу, кто-то - опасности электричества, кто-то - того, как это отразится на обществе. С нейронками сейчас происходит ровно то же самое
Ну это равносильно тому, что дать команду нейронке «Напиши программу на Python для вывода сообщения «Hello World» в терминал» или самому написать
На мой взгляд так использовать нейросеть уж совсем глупо
Самое адекватное и при этом лаконичное мнение на этот счет, которое я только встречал. Люто плюсую и не понимаю возгласов про то, что нейросети у кого-то там заберут работу. Электричество забрало работу у фонарщиков, а будильник забрал работу у тех, кто длинной палкой с улицы стучал по окну человеку в нужное время
Если вы боитесь, что инструмент, технология или автоматизация процесса может забрать у вас работу, стоит задуматься, а не холиварить прогресс
Если возникнут какие-то вопросы по этому процессу или что-то захотите уточнить, напишите мне в лс на Хабре или в тг (@MaxiEnergy)
Помогу, подскажу, поддержу
Как и приличное количество людей в комментариях к товару
Спасибо, что прочитали статью и поделились своим мнением) Я думал поэкспериментировать с прошивкой. Может все таки по дополнительному функционалу еще подумаю. Если надумаю, будет ещё одна статья)
Сейчас заметил в схеме. Ничего сверхъестественного, это просто мой косяк. Спасибо, что сказали. Исправил
Яндекс пишет, что инерционный. Я решил с ними в этом не спорить. С точки зрения механизма я с вами согласен, это заводной 100%
Я очень рад, что Вы продолжаете следить за моими статьями) Большое спасибо за комментарий
Спасибо за совет) В следующих проектах попробую ее
Про аутентификацию я с вами полностью согласен. Как раз в устройстве SmartPulse я реализовывал тот механизм, на который вы ссылаетесь, с генерацией шестизначного рандомного пин-кода и последующим выводом на экран устройства. Доступ к нему предоставляется после введения пин-кода в приложении Smart Connect. То есть, характеристики закрыты до тех пор, пока не произойдет проверка введенного в приложении пин-кода на уровне прошивки устройства.
Про кнопку ничего сказать не могу, я в стандарте этого не видел. По сути, сама проблема безопасности Интернета вещей как концепции и устройств IoT в частности заключается даже не в использовании уязвимостей технологий беспроводной передачи данных и прочего, а просто в нежелании «разработчика» хотя бы мало-мальски постараться над механизмами безопасности своего продукта. С точки зрения человека я могу это понять, потому что мало кто идет проверяться у стоматолога, пока зуб не заболит. Но на мой взгляд это все таки проблема, потому что важно осознавать последствия, которые могут возникать из-за такой халатности.
Спасибо за комментарий!
Спасибо за идею с более элегантным способом. Я как-то сам до этого не дошел, хотя по сути, способ много где используется.
Ну про фичу согласен. Только на мой взгляд это не должно никоим образом мешать безопасности устройства в целом. С тем же SmartPulse я же не запретил доступ в принципе. Можно спокойно подключиться к нему, можно посмотреть все сервисы и характеристики. То есть, при желании написать кастомный клиент, я предусмотрел эту возможность. Но прочитать что-либо из характеристик или записать в них без первоначального введения временного пин-кода - невозможно (или трудно выполнимо, чтобы не кидаться громкими словами). По сути, смысл всей статьи был в этом.
Огромное спасибо за комментарий!
Поэтому я привел в пример историю с коммерческим устройством. То есть, смысл в том, что не обязательно знать коды управления (при наличии времени и желания их можно подобрать), чтобы получить доступ к устройству и как минимум попробовать им управлять. Ну и про открытые характеристики туда же. Хотя звучит, может, и не особо убедительно
Большое спасибо) Это очень приятно читать
Про колонки и прочее - тут просто самой цели именно в этом не было, поэтому работал с тем, что подвернулось под руку. Я дальше планирую на Flipper Zero попробовать поиграться с моими устройствами и с разными коммерческими, если время будет
С последним тезисом про безопасность, как фичу, не совсем согласен. Из-за такого подхода мы и говорим про интернет вещей, как про что-то совершенно лишенное защиты. А потом появляются статьи про взломы умных лампочек и компрометацию ПДн пользователя, через получение доступа к умному устройству, как к посреднику для более направленного вектора атаки на мобильное устройство или любое другое, которое уже точно стоит защищать. Чем меньше уязвимых звеньев мы в этой цепочке оставляем, тем сложнее и замороченнее провести атаку.
По поводу комфорта пользователя - наиболее комфортный и удобный вариант со стороны пользователя, это обычно когда вообще не требуется ни пароль свой вспоминать, ни код двухфакторки вводить, ни париться с восстановление доступа к аккаунту в основном мобильном приложении для устройств Интернета вещей. Тут понятно, что генерировать пин-код для ввода каждый раз это не удобно для пользователя. Ок, я согласен. Поэтому придумываются различные автозаполнения и прочее, чтобы пользователь не так сильно напрягался по работе с приложением или устройством. В случае пульсометра - не хочется вбивать пин-код? Пускай аутентификация происходит по QR-коду на его дисплее через мобильное приложение. Камеру телефона навел и подключился. Красота же.
По модели угроз и прочего я согласен полностью, про это я уже говорил. Но то, что у меня продемонстрировано в дипломе, в принципе, не нужно воспринимать как реальную ситуацию. Да, в данном конкретном случае защищать пульсометр в целом не имеет смысла, потому что даже в мобильном приложении нет никаких пользовательских данных. Ок. А что, если бы они были? А что, если мы говорим о потенциальной платформе IoT для множества устройств в одной единой экосистеме? Там будут пользовательские данные и устройства будут явно не уровня пульсометра. Да, нужна модель угроз, я согласен, и я согласен с тем, что невозможно ее сформировать на «идею», а не на четко разрабатываемую ИС, где в явном виде будет понятна и классификация ПДн, и потенциал нарушителя, и определенна ценность информации, и способ взаимодействия с ней. Но ведь задача моего диплома изначально заключалась в ином. Подход от мат модели показать, как наиболее оптимальный метод в рамках ограниченности ресурсов.
На мой взгляд, тему надо допилить вместе с зависимостью от МУиН напрямую для определения наиболее эффективных сценариев защиты. Диплом ведь про это, а не про то, что я определил механизмы защиты, защитил ими устройство, и рекомендую всем так делать.
За вашу оценку моего диплома и настолько подробные комментарии в любом случае спасибо. Для меня важно любое аргументированное мнение и позиция
Да я в целом в статье не рекомендую подобные вещи в явном виде сравнивать. Строки - не самая большая беда, учитывая то, что я не использую никакого хэширования.
За то, что заметили косяк с использованием строк в C - респект. Приятно, что на мою статью обратил внимание опытный и грамотный специалист. Я не могу сказать, что не знал про этот недостаток, но на этапе написания работы времени минимизировать такие допущения у меня не оставалось, а для статьи я решил исходники не переписывать, чтобы оставаться до конца честным (иначе это была бы уже не моя ВКР, а что-то совершенно отдельное).
По самой работе, практикам ИБ и прочему - если бы это касалось реальной разработки устройства в рамках организации или стартапа, подход в принципе сильно бы отличался. Не только по качеству кода, но и к проектированию устройства и определению механизмов защиты в принципе. Про модель угроз я уже выше написал, почему пришлось от нее отказаться.
Я никогда не утверждал, что это самый эффективный и работоспособный вариант. Но правда я верю, что он не бесперспективен как минимум. Отсюда вопрос: если вы ознакомились со всеми опубликованными частями цикла или посмотрели оригинал ВКР, как вы думаете, в каком направлении углублять это исследование, чтобы получилось что-то реально рабочее? Есть у вас какие-то предложения? Может завязать определение механизмов защиты на сложности реализации атак по потенциалу злоумышленника или в мат модели показатели приоритета расширить в соответствии с МУиН?
Спасибо, что поделились своим мнением
По поводу модели угроз я с вами согласен. У меня были мысли хотя бы минимально определить нарушителя в рамках дипломной работы, но она в итоге и без того вышла достаточно объемной, поэтому решил опустить часть с МУиН.
Относительно защиты - я в самой статье упоминал, что цель заключалась не в демонстрации наиболее правильного процесса обеспечения безопасности устройства и концепции безопасной разработки, а в том, как в теории можно использовать методику на математической модели, которая мной в первой части описывалась.
Если бы я полноценно подготовил МУиН на ИС из пользователя, устройства и мобильного приложения, дипломная работа стала бы толще ещё на несколько десятков страниц, но в рамках реальной разработки она безусловно нужна.
Спасибо за то, что прочитали статью и написали комментарий
Огромное спасибо, что прочитали статью. Отдельное спасибо за то, что считаете мою статью крутой. Не забрасывайте тему безопасности IoT. Она затрагивает много важных и актуальных вещей
С трансформатором вариант хороший. Тоже возьму на вооружение