Комментарии 6
Что за безопасность без модели угроз? От чего именно устройство защищено?
По поводу модели угроз я с вами согласен. У меня были мысли хотя бы минимально определить нарушителя в рамках дипломной работы, но она в итоге и без того вышла достаточно объемной, поэтому решил опустить часть с МУиН.
Относительно защиты - я в самой статье упоминал, что цель заключалась не в демонстрации наиболее правильного процесса обеспечения безопасности устройства и концепции безопасной разработки, а в том, как в теории можно использовать методику на математической модели, которая мной в первой части описывалась.
Если бы я полноценно подготовил МУиН на ИС из пользователя, устройства и мобильного приложения, дипломная работа стала бы толще ещё на несколько десятков страниц, но в рамках реальной разработки она безусловно нужна.
Спасибо за то, что прочитали статью и написали комментарий
if (strcmp(pincode, passkey) == 0) { // Сравнение полученного пин-кода с сохраненным
is_authenticated = true; // Установка флага аутентификации в случае успеха
}Сравнивать что-то как строки - это прямо классика, в свое время так Intel пролетел с AMT, Nintendo с шифрованием игр для Wii, имя им легион.
Товарищ, вы диплом по инфобезу уже получили, конечно, но за такую вот фигню я бы вам оценку немного снизил. Никогда не сравнивайте никакие относящиеся к безопасности вещи строковыми функциями из С, они работают совсем не совсем так, как вы ожидаете. И даже memcmp обычной сравнивать не нужно, потому что она уязвима к тайминг-атакам.
Понятно, что без модели угроз, про которую тут уже упомянули - это все фигня полная, ибо непонятно, что и от кого мы тут защищаем. Но если уж добавляете код в качестве примера - не делайте в нем такого рода ошибок, пожалуйста.
Да я в целом в статье не рекомендую подобные вещи в явном виде сравнивать. Строки - не самая большая беда, учитывая то, что я не использую никакого хэширования.
За то, что заметили косяк с использованием строк в C - респект. Приятно, что на мою статью обратил внимание опытный и грамотный специалист. Я не могу сказать, что не знал про этот недостаток, но на этапе написания работы времени минимизировать такие допущения у меня не оставалось, а для статьи я решил исходники не переписывать, чтобы оставаться до конца честным (иначе это была бы уже не моя ВКР, а что-то совершенно отдельное).
По самой работе, практикам ИБ и прочему - если бы это касалось реальной разработки устройства в рамках организации или стартапа, подход в принципе сильно бы отличался. Не только по качеству кода, но и к проектированию устройства и определению механизмов защиты в принципе. Про модель угроз я уже выше написал, почему пришлось от нее отказаться.
Я никогда не утверждал, что это самый эффективный и работоспособный вариант. Но правда я верю, что он не бесперспективен как минимум. Отсюда вопрос: если вы ознакомились со всеми опубликованными частями цикла или посмотрели оригинал ВКР, как вы думаете, в каком направлении углублять это исследование, чтобы получилось что-то реально рабочее? Есть у вас какие-то предложения? Может завязать определение механизмов защиты на сложности реализации атак по потенциалу злоумышленника или в мат модели показатели приоритета расширить в соответствии с МУиН?
Спасибо, что поделились своим мнением
Вы не с той стороны к проблеме подходите, потому что у вас пока "давайте реализуем кучу всяких разных защит на самодельном устройстве, потому что хотим их все попробовать", но при этом ничего нет про то, что вы защищаете, и от кого.
Основная теорема ИБ упрямо утверждает примерно следующее: "стоимость имеющей смысл защиты должна быть ниже, чем стоимость защищаемой ей информации", она же "стоимость обеспечения несанкционированного доступа к информации должна быть выше стоимости этой информации", она же закон Склярова. Так вот, еще до того, как идти городить матмодель и защищать ИоТ-устройства (от кого?), надо сначала понять, а что мы там защищаем? А надо ли?
Ну т.е. у вас вот нательный датчик, какие ценные данные он генерирует, чтобы для него делать все, что вы тут решили делать? У вас треки GPS-координат? У вас там платежные данные и банковские карты? Или может список контактов с телефона подтянутый?
Дальше, поняли что защищаем, теперь надо понять, от кого, и есть ли у атакующего вообще какой-либо смысл делать такую атаку. Ну т.е. если у вас на вашем ИоТ устройстве хранятся мастер-ключи к супер-популярному репозиторию с миллиардом загрузок в сутки, то защищать его надо будет сильно более интересным способом (вплоть до монтирования внутрь бетонного куба и специальных ритуалов с несколькими ключами) чем если у вас там финтес-треккер, который кроме пульса и количества шагов ничего не отслеживает, и кроме телефона ни с чем не соединен.
Вот только после ответа на эти простые, но главные вопросы, надо идти думать, а нужны ли вам постоянно меняющиеся пинкоды (это неудобно пользователю) или зашифрованная прошивка (а это вообще подстава, нужная только как защита от передирания первой партии устройств китайским заводом, а для пользователя вредная, потому что не позволяет устройство ни дорабатывать, ни починить), и прочие все записи из радужной диаграммы.
То, что сделано - отличный диплом без дураков, попробовали кучу всякого, про все написали, радуемся. Но развивать это не надо, потому что устройства - они для пользователя, и безопасность в них - это не цель, это фича, причем зачастую не очень нужная.
С последним тезисом про безопасность, как фичу, не совсем согласен. Из-за такого подхода мы и говорим про интернет вещей, как про что-то совершенно лишенное защиты. А потом появляются статьи про взломы умных лампочек и компрометацию ПДн пользователя, через получение доступа к умному устройству, как к посреднику для более направленного вектора атаки на мобильное устройство или любое другое, которое уже точно стоит защищать. Чем меньше уязвимых звеньев мы в этой цепочке оставляем, тем сложнее и замороченнее провести атаку.
По поводу комфорта пользователя - наиболее комфортный и удобный вариант со стороны пользователя, это обычно когда вообще не требуется ни пароль свой вспоминать, ни код двухфакторки вводить, ни париться с восстановление доступа к аккаунту в основном мобильном приложении для устройств Интернета вещей. Тут понятно, что генерировать пин-код для ввода каждый раз это не удобно для пользователя. Ок, я согласен. Поэтому придумываются различные автозаполнения и прочее, чтобы пользователь не так сильно напрягался по работе с приложением или устройством. В случае пульсометра - не хочется вбивать пин-код? Пускай аутентификация происходит по QR-коду на его дисплее через мобильное приложение. Камеру телефона навел и подключился. Красота же.
По модели угроз и прочего я согласен полностью, про это я уже говорил. Но то, что у меня продемонстрировано в дипломе, в принципе, не нужно воспринимать как реальную ситуацию. Да, в данном конкретном случае защищать пульсометр в целом не имеет смысла, потому что даже в мобильном приложении нет никаких пользовательских данных. Ок. А что, если бы они были? А что, если мы говорим о потенциальной платформе IoT для множества устройств в одной единой экосистеме? Там будут пользовательские данные и устройства будут явно не уровня пульсометра. Да, нужна модель угроз, я согласен, и я согласен с тем, что невозможно ее сформировать на «идею», а не на четко разрабатываемую ИС, где в явном виде будет понятна и классификация ПДн, и потенциал нарушителя, и определенна ценность информации, и способ взаимодействия с ней. Но ведь задача моего диплома изначально заключалась в ином. Подход от мат модели показать, как наиболее оптимальный метод в рамках ограниченности ресурсов.
На мой взгляд, тему надо допилить вместе с зависимостью от МУиН напрямую для определения наиболее эффективных сценариев защиты. Диплом ведь про это, а не про то, что я определил механизмы защиты, защитил ими устройство, и рекомендую всем так делать.
За вашу оценку моего диплома и настолько подробные комментарии в любом случае спасибо. Для меня важно любое аргументированное мнение и позиция
Диплом специалиста ИБ. Часть №3 — Портативное устройство SmartPulse