Если есть желание получать все уязвимости относящиеся к продукту, то можно подписаться на все что есть, ведь уязвимость она всегда в какой-то конкретной версии браузера, а не в целом в Мозилле.
До настоящего времени, с такой конфигурацией на практике не встречались, поэтому от нас такой проверки не требовали.
Но если в вашей Компании используется MaxPatrol, заведите заявку на https://support.ptsecurity.com/. Мы обсудим детали и постараемся сделать такую проверку ;)
Про ключ tacacs+/radius не говорилось, впрочем и про остальные параметры tacacs+/radius тоже. Это отдельная тема.
В статье специально указано, что перечислены наиболее распространенные методы аутентификации. Аутентификация через LDAP в нашей практике встречается путем использования протокола radius и сервера Cisco ACS.
Случай заведения пользователя LDAP на Cisco, не совсем хороший пример и с точки зрения безопасности. Ведь в случае получения конфигурации устройства злоумышленником, пароль пользователя LDAP может быть восстановлен со всеми вытекающими….
MaxPatrol проверят авторизацию и учет событий, но в них схема отлична от аутентификации. Поэтому и описали только про аутентификацию
Описанный в статье поиск абонента не претендует на абсолютную универсальность. Атакующему в первую очередь нужно понимать цель для своих поисков и достаточную точность.
У многих операторов мобильной связи (у операторов Б3 точно) есть услуга определения местоположения по базовым станциям GSM. На сайте оператора наверняка найдёте такую услугу. Точность определения зачастую будет выше, чем в описанном выше сценарии, т.к. у оператора есть возможность собирать информацию с нескольких базовых станций своей сети и рассчитывать примерное расстояние до каждой из БС по уровню сигнала (параметр Timing Advance).
Таймер для процедуры Periodic Location Update устанавливается, как правило, в значение нескольких часов. Если полагаться только на Periodic LU, то вероятность точности местоположения будет значительно ниже. Чтобы приблизить определение местоположения к реальному времени, нужно вынуждать мобильный аппарат делать активность на сети. Выбор SMS-пинга определяется тем, что это происходит незаметно для абонента.
По факту, у операторов связи позиция чаще всего выглядит так: «Сеть работает стабильно, поэтому не нужно внедрять ничего лишнего». Такую точку зрения тоже можно понять, т.к. оператор нацелен в первую очередь на получение прибыли, и во главу угла ставится надёжность сервиса. В настоящее время наблюдается смещение приоритетов в сторону безопасности, но процесс этот идёт пока довольно медленно.
Сорри за разную трактовку одной и той же аббревиатуры :)
Если у оператора будут исключения в работе указанных в статье сообщений SS7, то оператор рискует не дополучать трафик роуминговых абонентов, что не в его интересах.
В качестве исключений, скорее, можно указать следующие моменты:
1. Фильтрацию подозрительных SS7 сообщений.
2. Особенности работы мобильного аппарата при обработке SMS-пинга: некоторые модели телефонов не отвечают на такой запрос из сети.
Информацию о местоположении (MCC+MNC+LAC+CID) отдает не ОSS (Operation Support System), а мобильный коммутатор MSC. Атака строится на стандартных сообщениях протокола MAP. Все поставщики оборудования придерживаются стандартов и общих спецификаций протоколов. Кстати, в статье приведен пример именно международного уровня.
Инженер может посмотреть в ОСС данные своих абонентов. В статье описан принцип получения информации о местоположении практически любого абонента в любом месте.
Например, китайский инженер может узнать местонахождение депутата Британского парламента, зная только номер его мобильного телефона.
Да, у телефонных операторов есть доступ к SS7, но, как правило, он ограничивается протоколом ISUP. С его помощью провести такую атаку не удастся. Интернет-провайдеры обеспечивают иные сервисы, подключения к SS7 для коммерческих целей у них быть не должно.
Возможно это так. Речь в статье идет о различных подходах к автоматизации тестирования приложений с точки зрения безопасности. По сути это одна из статей цикла, более ранние, касающиеся вопросов закладок, НДВ, статического и динамического анализа можно найти тут и тут.
Дело в том, что одной из проблем SAST является потенциально большое количество ложных срабатываний. Например тут найдено 57000+ «уязвимостей». Причем большая часть — ложные срабатывания. Разбирать руками? Фиксить все?
Ну и кроме того, верификация уязвимости путем «посмотреть код глазками» может быть более трудоемкой разботой, чем отправить запрос server/script?search=">alert('xoked'), если, конечно средство предоставляет такие данные.
Да, у вас сложный случай. Мне сложно что-то вот так посоветовать, не видя проект/код, но рискну предоставить пару общих рекомендаций.
Начните с чего-то попроще, например, с чистой функции или класс. Обычно есть какие-нибудь общие библиотеки функций на проекте, например QstringToString/StringToQString, всякие функции перекодирования из LowEndian в BigEndian и прочая полезная мелочь.
Я бы начал именно с этой мелочи. Рекомедую взять gtest и gmock — это отличные фрэйворки для тестрования C/C++ кода.
Набрав начальный необходимый вес (критическую массу/количество тестов), потом станет значительно легче. Старые тесты будут давать вам основу для написания новых :-), почувствуете почву под ногами :-)
У нас был похожий случай. Часть первых тестов, которые сделали, были очень сложными, и потом мы их просто выкинули и заменили уже «правильными простыми тестами».
Но эти плохие написанные нами тесты дали понимание, как нам правильно тестировать наш проект, которому уже 10 лет и в котором тоже намешана сборная солянка.
Поэтому, рекомендую начать с простых библиотечных функций, набьёте руку на них, и станет понятно, как писать тесты именно для вашего конкретного проекта.
Вам ГРОМАДНУЮ помощь окажет книга М.Физерса «Эффективная работа с унаследованным кодом» (http://www.ozon.ru/context/detail/id/4311012/).
В ней очень хорошо разбирается старый код на C++.
Нас было 5 разработчиков на проекте. Все перешли на разработку с тестами и инспекциями достаточно быстро.
На введение в процесс разработки инспекции кода нам понадобилась 2 недели.
1) а через месяц у нас появился документ codingstyle;
2) весь код стал проходить инспектирование, было как-то стрёмно закомитить непроинспектированный код — это же всегда заметно(если кто-то считает что незаметно — скорей всего, обманывает сам себя);
3) мы стали больше общаться вживую, появились обсуждения разных подходов разработки;
4) стали лучше понимать друг друга, уважение выросло на порядок.
С тестами подольше. В конце концов все переключились на разработку с тестами от одного месяца до полугода. На новый код писали тесты. Делали швы по рекомендациям книги М.Физерса «Эффективная работа с унаследованным кодом» (http://www.ozon.ru/context/detail/id/4311012/).
На те места, где приходилось рефакторить — в обязательном порядке писали тесты. Да, были ошибки, да было непросто, но все мои бывшие коллеги согласны в одном — написание тестов в унаследованном проекте того стоило. Это мнение как самих разработчиков, так и менеджеров проекта, отдела сопровождения, отдела внедрения.
Это же супер: приезжаешь на объект, настраиваешь и уезжаешь (забываешь про него :-)
Не так давно понял одно высказывание по новому.
«Компьютер должен быть продуктивным, а человеку лучше быть эффективным.»
Когда я пишу код без тестов и без инспекций кода — меня можно считать продуктивным, я быстро «педалю код».
Когда я пишу код с тестами и провожу инспекции кода — меня можно считать эффективным, я строю надолго/качественно/без суеты сложные большие системы.
Но если в вашей Компании используется MaxPatrol, заведите заявку на https://support.ptsecurity.com/. Мы обсудим детали и постараемся сделать такую проверку ;)
В статье специально указано, что перечислены наиболее распространенные методы аутентификации. Аутентификация через LDAP в нашей практике встречается путем использования протокола radius и сервера Cisco ACS.
Случай заведения пользователя LDAP на Cisco, не совсем хороший пример и с точки зрения безопасности. Ведь в случае получения конфигурации устройства злоумышленником, пароль пользователя LDAP может быть восстановлен со всеми вытекающими….
MaxPatrol проверят авторизацию и учет событий, но в них схема отлична от аутентификации. Поэтому и описали только про аутентификацию
Если у оператора будут исключения в работе указанных в статье сообщений SS7, то оператор рискует не дополучать трафик роуминговых абонентов, что не в его интересах.
В качестве исключений, скорее, можно указать следующие моменты:
1. Фильтрацию подозрительных SS7 сообщений.
2. Особенности работы мобильного аппарата при обработке SMS-пинга: некоторые модели телефонов не отвечают на такой запрос из сети.
Например, китайский инженер может узнать местонахождение депутата Британского парламента, зная только номер его мобильного телефона.
Ну и кроме того, верификация уязвимости путем «посмотреть код глазками» может быть более трудоемкой разботой, чем отправить запрос server/script?search=">alert('xoked'), если, конечно средство предоставляет такие данные.
Начните с чего-то попроще, например, с чистой функции или класс. Обычно есть какие-нибудь общие библиотеки функций на проекте, например QstringToString/StringToQString, всякие функции перекодирования из LowEndian в BigEndian и прочая полезная мелочь.
Я бы начал именно с этой мелочи. Рекомедую взять gtest и gmock — это отличные фрэйворки для тестрования C/C++ кода.
Набрав начальный необходимый вес (критическую массу/количество тестов), потом станет значительно легче. Старые тесты будут давать вам основу для написания новых :-), почувствуете почву под ногами :-)
У нас был похожий случай. Часть первых тестов, которые сделали, были очень сложными, и потом мы их просто выкинули и заменили уже «правильными простыми тестами».
Но эти плохие написанные нами тесты дали понимание, как нам правильно тестировать наш проект, которому уже 10 лет и в котором тоже намешана сборная солянка.
Поэтому, рекомендую начать с простых библиотечных функций, набьёте руку на них, и станет понятно, как писать тесты именно для вашего конкретного проекта.
Вам ГРОМАДНУЮ помощь окажет книга М.Физерса «Эффективная работа с унаследованным кодом» (http://www.ozon.ru/context/detail/id/4311012/).
В ней очень хорошо разбирается старый код на C++.
Желаю вам решиться :-)
Чтобы он понял вашу точку зрения, вам скорее всего потребуется вначале понять его.
Можно попробовать пролистать вот эти книжки:
Just Listen: Discover the Secret to Getting Through to Absolutely Anyone(http://www.amazon.com/Just-Listen-Discover-Getting-Absolutely/dp/0814414036)
Becoming a Technical Leader: An Organic Problem-Solving Approach (http://www.amazon.com/Becoming-Technical-Leader-Problem-Solving-Approach/dp/0932633021/ref=sr_1_1?s=books&ie=UTF8&qid=1376559982&sr=1-1&keywords=becoming+a+technical+leader)
Честно говоря — я редко встречал «тупых» людей, непонятых — постоянно.
Имхо, конечно всё.
Какой системе вы могли бы передать ответственность за свой палец(согласен, палец жалко — машину :-)), например?
Той, которая пишется с тестами и инспекциями кода или той, которая без тестов и без инспекций?
На введение в процесс разработки инспекции кода нам понадобилась 2 недели.
1) а через месяц у нас появился документ codingstyle;
2) весь код стал проходить инспектирование, было как-то стрёмно закомитить непроинспектированный код — это же всегда заметно(если кто-то считает что незаметно — скорей всего, обманывает сам себя);
3) мы стали больше общаться вживую, появились обсуждения разных подходов разработки;
4) стали лучше понимать друг друга, уважение выросло на порядок.
С тестами подольше. В конце концов все переключились на разработку с тестами от одного месяца до полугода. На новый код писали тесты. Делали швы по рекомендациям книги М.Физерса «Эффективная работа с унаследованным кодом» (http://www.ozon.ru/context/detail/id/4311012/).
На те места, где приходилось рефакторить — в обязательном порядке писали тесты. Да, были ошибки, да было непросто, но все мои бывшие коллеги согласны в одном — написание тестов в унаследованном проекте того стоило. Это мнение как самих разработчиков, так и менеджеров проекта, отдела сопровождения, отдела внедрения.
Это же супер: приезжаешь на объект, настраиваешь и уезжаешь (забываешь про него :-)
Не так давно понял одно высказывание по новому.
«Компьютер должен быть продуктивным, а человеку лучше быть эффективным.»
Когда я пишу код без тестов и без инспекций кода — меня можно считать продуктивным, я быстро «педалю код».
Когда я пишу код с тестами и провожу инспекции кода — меня можно считать эффективным, я строю надолго/качественно/без суеты сложные большие системы.
Имхо, конечно всё.