Пожалуй, вы правы. Сказки — это вымышленные истории, прошедшие жестокий отбор в сотнях лет пересказов и перепечаток. Глупые герои и неинтересные стратегии в этом отборе проиграли. В итоге сказка — это коллекция живых и боевых мемов.
По сравнению с этим покемоны — всего лишь выдуманные недавно персонажи. Возможно, через двадцать лет их никто не вспомнит.
Поэтому для настоящих сказочных героев просто оскорбительно, если в один ряд с ними поставить вымышленную помесь кролика с удавом, названную «покемоном». Царевна-Лягушка и Красная Шапочка даже поесть не сядут рядом.
Может быть, лучше использовать термин «виртуальные персонажи»? Это включает любую ерунду, которая шевелится на экране.
Да, SNMPv3 и доступ только с разрешённых адресов — тоже варианты. Мы про них рассказывали в прошлой публикации по этой теме:
https://habrahabr.ru/company/pt/blog/247355/
Как верно заметили выше, в конце статьи изложены несколько полезных правил. Кроме того, в статье есть ссылка на наш разбор конкретного кейса: работа по протоколу SNMP с уязвимым сетевым оборудованием HP/H3C и Huawei. В конце этого кейса есть раздел «Как защититься» с некоторыми подробностями по защите — посмотрите:
Возможно, вы впервые сталкиваетесь с обобщенными статистическими исследованиями. В таком случае, вот суровая правда: такие исследования почти всегда представляют собой «среднюю температуру по больнице». Почитайте статистику FireEye (Mandriant Report) или Verizon DBIR.
Тем не менее, некоторые выводы из такой обобщенной аналитики сделать можно. Например, Mandiant Report 2013 рассказывается, что 100% взломанных в 2013 году компаний имели у себя регулярно обновляемый антивирус. Там не рассказано про «стоимость систем, сроки разработки и уровень подготовки специалистов». Но тем не менее, сам факт беспомощности антивирусов — интересный.
В нашем случае вывод состоит в том, что приложения на PHP в последние годы стали более безопасными. Это ровно то, что показывает обобщенная статистика. Ни больше, ни меньше.
Мы рассказали об этом владельцем тех систем, которые были исследованы. Относительно того, стоит ли рассказывать всему миру, у нас есть понятие «политика ответственного разглашения». Это значит, что мы расскажем о конкретных уязвимостях тогда, когда сочтём, что этот рассказ сам по себе не создаёт проблему безопасности.
Кстати, в нашем блоге вы можете найти множество подобных рассказов о конкретных уязвимостях. И можете заметить в них приписку типа «Уязвимость устранена производителем». Например:
>На графике «какой-то показатель» уязвимостей среднего уровня
>равен 100% для всех языков!!!
Не для всех языков, а для всех протестированных систем. График показывает долю систем с уязвимостями данного уровня риска (по языкам). Это значит, что уязвимости среднего уровня найдены во всех приложениях — и на PHP, и на Java. При этом данный график не говорит, сколько таких уязвимостей в отдельной системе. Он просто говорит, есть они там или нет.
А если вам интересно, сколько именно уязвимостей среднего уровня найдено в системах на PHP и в системах на Java, посмотрите полный текст исследования. Там есть другой график. И сравнительная процентовка действительно разная получается.
>а у Other — практически в ноль должен уходить
Дело в том, что Other (Другие) — это не один, а несколько языков программирования, менее популярных, чем PHP и Java. Поэтому, если вам хочется узнать долю критических уязвимостей на *каждый* отдельный язык из Других, вам надо поделить общую долю в соответствующей пропорции.
Именно поэтому и получается, что общая доля уязвимостей Других языков — велика, но на каждый язык приходится гораздо меньше, чем в случае Java и PHP.
>И никому (ок-ок — мне) в потоке «Разработка» не интересно
Дело в том, что поток «Разработка» придуман недавно. Почему администрация Хабра впихнула туда наш блог, не очень понятно. Нас не спрашивали. В течение многих лет наш блог находится в хабе «Информационная безопасность». Вот это действительно соответствует нашей тематике.
Да, мы частенько публикуем материалы, которые связаны, например, с безопасной разработкой, с конкретными примерами кодов (полистайте блог). Но мы не собираемся ограничиваться одной лишь «разработческой» тематикой только потому, что месяц назад кто-то решил запихать наш блог в поток «Разработка».
Поэтому, если у вас есть претензии по поводу того, почему исследования, новости, анонсы конференций или разборы нормативных документов по безопасности попадают и будут попадать в «Разработку» — эти все претензии адресуйте администрации Хабра, которая придумала такую странную категоризацию материалов.
>Вот было бы неплохо услышать каким образом банкомат становится «тем самым банкоматом»
Скажите честно: у вас есть какие-то психологические блоки, которые мешают полистать наш блог, или просто через поиск найти наши материалы про банкомат? Вот например:
>или услышать про проблемы написания кода, который этого избежит
… Или может, это просто болезнь поколения — «вижу только последний пост в мобиле»? Вот вам про безопасную разработку банковских приложений. В два клика находится.
Ссылка в конце поста ведет на полные тексты наших исследований. Там просто больше графиков и подробностей для тех, кому это интересно.
Кстати, следующее исследование, которое здесь будет опубликовано, посвящено именно уязвимым банковским приложениям. Зайдите на следующей неделе, если вы всё ещё не позакрывали свои банковские клиенты.
Что касается «маркетинга»: было бы интересно узнать, какие-такие «продавцы» давали вам ссылки на свои ежегодные исследования уязвимостей веб-приложений, АСУ ТП, мобильных операторов и ДБО. Может, это были продавцы мороженого?
Во всех успешных тестах в детализации вызовов отображались только вызываемые номера. В данной атаке конференц-связь устанавливается не в сети оператора, а на внешнем коммутаторе, поэтому факт конференции никак не может отразиться в детализации вызовов.
>> Затем подконтрольный коммутатор направляет вызов на оборудование товарища майора, который организовывает конференц-связь между прослушиваемыми абонентами и товарищем майором?
— Да.
>>В стандартной детализации вызовов этот сеанс связи отобразится с указанием номера товара майора?
— В стандартной детализации отображается набранный номер. Номер злоумышленника в детализации не фигурирует.
>> Если подконтрольный коммутатор находится в другой стране — как отразится на состоянии лицевого счета инициатора звонка?
— Для препейдного абонента вызов проходит в обход реальной биллинговой платформы. Если будет происходить сверка CDR с базой онлайн биллинга, то абоненту позже могут предъявить счёт. Но, как правило, такая сверка происходит при серьёзном расхождении начислений в базах CDR и биллинговой платформы.
>>Какова причина неудач в оставшейся половине аттак?
— Некоторые операторы не позволяют изменять профиль абонента из внешних сетей, поэтому перенаправление вызова в этих случаях было невозможно.
По сравнению с этим покемоны — всего лишь выдуманные недавно персонажи. Возможно, через двадцать лет их никто не вспомнит.
Поэтому для настоящих сказочных героев просто оскорбительно, если в один ряд с ними поставить вымышленную помесь кролика с удавом, названную «покемоном». Царевна-Лягушка и Красная Шапочка даже поесть не сядут рядом.
Может быть, лучше использовать термин «виртуальные персонажи»? Это включает любую ерунду, которая шевелится на экране.
https://habrahabr.ru/company/pt/blog/247355/
Как верно заметили выше, в конце статьи изложены несколько полезных правил. Кроме того, в статье есть ссылка на наш разбор конкретного кейса: работа по протоколу SNMP с уязвимым сетевым оборудованием HP/H3C и Huawei. В конце этого кейса есть раздел «Как защититься» с некоторыми подробностями по защите — посмотрите:
https://habrahabr.ru/company/pt/blog/247355/
http://approof.ptsecurity.ru/
Тем не менее, некоторые выводы из такой обобщенной аналитики сделать можно. Например, Mandiant Report 2013 рассказывается, что 100% взломанных в 2013 году компаний имели у себя регулярно обновляемый антивирус. Там не рассказано про «стоимость систем, сроки разработки и уровень подготовки специалистов». Но тем не менее, сам факт беспомощности антивирусов — интересный.
В нашем случае вывод состоит в том, что приложения на PHP в последние годы стали более безопасными. Это ровно то, что показывает обобщенная статистика. Ни больше, ни меньше.
Мы рассказали об этом владельцем тех систем, которые были исследованы. Относительно того, стоит ли рассказывать всему миру, у нас есть понятие «политика ответственного разглашения». Это значит, что мы расскажем о конкретных уязвимостях тогда, когда сочтём, что этот рассказ сам по себе не создаёт проблему безопасности.
Кстати, в нашем блоге вы можете найти множество подобных рассказов о конкретных уязвимостях. И можете заметить в них приписку типа «Уязвимость устранена производителем». Например:
https://habrahabr.ru/company/pt/blog/280095/
https://habrahabr.ru/company/pt/blog/276459/
https://habrahabr.ru/company/pt/blog/255929/
https://habrahabr.ru/company/pt/blog/250675/
>И при этом мир не рухнул
Лучший ответ на этот вопрос дала девочка из фильма «Семейка Адамсов»:
— Just wait.
>равен 100% для всех языков!!!
Не для всех языков, а для всех протестированных систем. График показывает долю систем с уязвимостями данного уровня риска (по языкам). Это значит, что уязвимости среднего уровня найдены во всех приложениях — и на PHP, и на Java. При этом данный график не говорит, сколько таких уязвимостей в отдельной системе. Он просто говорит, есть они там или нет.
А если вам интересно, сколько именно уязвимостей среднего уровня найдено в системах на PHP и в системах на Java, посмотрите полный текст исследования. Там есть другой график. И сравнительная процентовка действительно разная получается.
>а у Other — практически в ноль должен уходить
Дело в том, что Other (Другие) — это не один, а несколько языков программирования, менее популярных, чем PHP и Java. Поэтому, если вам хочется узнать долю критических уязвимостей на *каждый* отдельный язык из Других, вам надо поделить общую долю в соответствующей пропорции.
Именно поэтому и получается, что общая доля уязвимостей Других языков — велика, но на каждый язык приходится гораздо меньше, чем в случае Java и PHP.
Дело в том, что поток «Разработка» придуман недавно. Почему администрация Хабра впихнула туда наш блог, не очень понятно. Нас не спрашивали. В течение многих лет наш блог находится в хабе «Информационная безопасность». Вот это действительно соответствует нашей тематике.
Да, мы частенько публикуем материалы, которые связаны, например, с безопасной разработкой, с конкретными примерами кодов (полистайте блог). Но мы не собираемся ограничиваться одной лишь «разработческой» тематикой только потому, что месяц назад кто-то решил запихать наш блог в поток «Разработка».
Поэтому, если у вас есть претензии по поводу того, почему исследования, новости, анонсы конференций или разборы нормативных документов по безопасности попадают и будут попадать в «Разработку» — эти все претензии адресуйте администрации Хабра, которая придумала такую странную категоризацию материалов.
>Вот было бы неплохо услышать каким образом банкомат становится «тем самым банкоматом»
Скажите честно: у вас есть какие-то психологические блоки, которые мешают полистать наш блог, или просто через поиск найти наши материалы про банкомат? Вот например:
https://habrahabr.ru/company/pt/blog/244159/
https://habrahabr.ru/company/pt/blog/246449/
>или услышать про проблемы написания кода, который этого избежит
… Или может, это просто болезнь поколения — «вижу только последний пост в мобиле»? Вот вам про безопасную разработку банковских приложений. В два клика находится.
https://habrahabr.ru/company/pt/blog/271287/
Кстати, следующее исследование, которое здесь будет опубликовано, посвящено именно уязвимым банковским приложениям. Зайдите на следующей неделе, если вы всё ещё не позакрывали свои банковские клиенты.
Что касается «маркетинга»: было бы интересно узнать, какие-такие «продавцы» давали вам ссылки на свои ежегодные исследования уязвимостей веб-приложений, АСУ ТП, мобильных операторов и ДБО. Может, это были продавцы мороженого?
— Да.
— В стандартной детализации отображается набранный номер. Номер злоумышленника в детализации не фигурирует.
— Для препейдного абонента вызов проходит в обход реальной биллинговой платформы. Если будет происходить сверка CDR с базой онлайн биллинга, то абоненту позже могут предъявить счёт. Но, как правило, такая сверка происходит при серьёзном расхождении начислений в базах CDR и биллинговой платформы.
— Некоторые операторы не позволяют изменять профиль абонента из внешних сетей, поэтому перенаправление вызова в этих случаях было невозможно.