Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: Пред. 1 2 3 4 След.
RSS
Будущее сканеров безопасности
 
Цитата
Nomad пишет:
Я всего лишь утверждаю, что устанавливать необходимо ВСЕ патчи.

Максимализм в безопасности тоже к добру не ведет. Поставив во главу угла обязательную установку ВСЕХ патчей и СРАЗУ, вы нарушаете нормальное ведение бизнеса. Пользователь будет вынужден тратить очень много времени на то, чтобы поставить все патчи, даже и не нужные в данный момент. Для администратора - это нормально, для человека бизнеса - это непозволительная роскошь.

Вот установлена у меня на компе система управления патчами, т.к. когда она мне говорит "хочу поставить патч", я ей в ответ "подожди, я сейчас важным делом занят, потом поставишь". И с точки зрения бизнеса это нормально - безопасность, к сожалению, всего лишь ПОМОГАЕТ вести бизнес, т.е. находится на втором (и хорошо если на втором) месте после зарабатывания денег.
Luka
 
Цитата
Гость пишет:
Ну расскажите тогда уважаемый про связку сканер и система установки патчей. В идеале Сканер обнаружил уязвимость - система автоматически натянула патч. Все в теории великолепно. Но где тут тестирование (какой его объем да и вообще, кто вам даст гарантию что оно после этого лучше будет работать?).

Это же обзор. Я не собирался расписывать все тонкости применения описанных технологий. Разумеется, в этой связке должно быть тестирования (я об это писал года 3-4 назад в статье про управление патчами).

Но на практике ситуация немного отличается от описанной тобой. Сканер обнаруживает уязвимость не сразу, как она появилась, а только после того, как информацию о ней поместили в сканер. А помещают ее в большинстве случаев только после того, как разработан патч (если не брать private exploit). Следовательно сам патч у тебя уже есть. Дальше, сканируешь ты не в момент появления дыры, а через какое-то время (например, о дыре стало известно в понедельник днем, а у тебя сканер должен быть запущен в пятницу). Значит у тебя есть время на тестирование патча и процесс этот не связан со сканированием - он самостоятелен. И вот мы подходим к моменту запуска сканера. Он обнаружил дыру и что? Патч у тебя уже есть. Время на его тестирование у тебя было. Осталось только установить его, что связка "сканер-система управления патчами" и делает.
Luka
 
Цитата
sec пишет:
если статья вышла за рамки сканеров безопасности (если нет, при чем тут тогда threat intelligence), то неплохо бы упомянуть про penetration testing

А она не вышла. В статье четко говорится о классе решений, называемых vulnerability management, к которым относятся и классические сканеры. Но на них список не заканчивается.

Threat Intelligence - это один из элементов этого процесса. Я еще лет 7-8 назад о нем писал. Когда у вас нет денег на приобретение сканера или сканер не поддерживает ваш софт, то у вас остается только один вариант - вручную устранять дыры, но для этого вы должны знать о них.

А penetration testing - это не софт и не решение, это услуга, которая, кстати, далеко не всегда выполняется с помощью сканеров безопасности. Тут важна именно квалификация тестеров. Если бы я начал анализировать еще и услуги, то мне пришлось бы много чего сюда еще добавить. Те же услуги по аудиту (обследованию), обучению, аутсорсингу и т.п.
Luka
 
Цитата
Михаил Политов пишет:
Интересный подход, хотя и довольно своеобразный. Интересно вас будет волновать крыша, которая может рухнуть с вероятностью 90% вам на голову, но пока ещё не рухнула лишь по причине отсутствия ветра?

Будет, она меня волнует, т.к. я сейчас ремонт как раз делаю ;-)   Поэтому я либо лично, либо с помошью доверенного прораба буду контролировать процесс ремонта/создания крыши. Но когда я живу в доме, состояние которого я не мог контролировать на процессе строительства, я приглашу технадзор и они мне оценят состояние моей крыши. Если вероятность ее сноса будет нулевой в обозримом будущем, то я рыпаться не буду. Если высокой, то я просто сменю место жительства, параллельно попробуя стрясти со строителей (в ПО это невозможно). А если риск невысокий, но есть, я задумаюсь о смене крыше (но не сразу) с одновременным страхованием своей жизни ;-)
Luka
 
Цитата
птЫца пишет:
Было бы интересно прочитать видение автора на данный путь развития сканеров.

Интересный поворот  :o   Использование сканера, как инструмент последущего взлома системы я даже не рассматривал  :cry:   И уж тем более хорошего коммерческого будущего у данных средств я не виже  :funny:
Luka
 
Цитата
LAG пишет:
автор выкинул мягко говоря в корзину целый пласт знаний называемый теорией надежности

 Не выкинул, просто большинство средств защиты эту теорию не учитывают, т.к. вынуждены бороться с тем, что есть в сети. И сканеру все равно насколько надежна система, если она все равно используется заказчиком.

Цитата
LAG пишет:
Автор ошибочно считает, что найденую дыру всегда можно пропатчить

 Я так не считаю ;-)  Я считаю, что любую дыру можно заткнуть - постоянно или на время, с помощью патча или временных ACL, отключением, в конце концов, уязвимого узла от сети. Все зависит от конкретной ситуации.

Цитата
LAG пишет:
Для критичных приложений - не используйте не надежные решения

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

Цитата
LAG пишет:
Защищайте свою сеть от удаленного сканирования

 О чем в статье также упомянуто и назван класс средств, решающих эту задачу, - host-based security scanners.
Luka
 
Алексей, очень рад конструктивному обсуждению :)

"Если вероятность ее сноса будет нулевой в обозримом будущем, то я рыпаться не буду."
А вы не считаете, что вероятность её сноса будет в значительной степени зависеть (хотя и не только от этого) от уровня критичности уязвимости, т.к. нападение на систему скорее всего будет осуществляться человеком, а это всё-таки процесс несколько менее случайный, нежели порывы ветра :) ?

"Если высокой, то я просто сменю место жительства, параллельно попробуя стрясти со строителей (в ПО это невозможно). А если риск невысокий, но есть, я задумаюсь о смене крыше (но не сразу) с одновременным страхованием своей жизни "

Вот, собственно, для этого методика и предлагалась - дабы дать предпосылки к тому, чтобы вы задумались и определили приоритеты   ;)
 
2NC.
1. Не надо оскорблять собеседника, тем более не зная его, можно попасть в неловкое положение. "Passive OS Fingerprinting (OSFP) is a method for passively detecting the operating system of a remote host based on certain characteristics within that host's TCP SYN packets. This information can then be used as criteria within filter rules." RTFM .... В любом случае Алексей Лукацкий прав (в ответе мне) - хост всегда может определить факт сканирования его автоматическим (!) средством.  
2Luka
1. Не соглашусь с тезисом "Люди используют удобный и красивые решение, а не самые надежные, которыми из-за этой самой надежности невозможно нормально пользоваться. ". Мне по душе другое "Делать правильно правильные вещи (Do The Right Thing) © (The Macintosh Way)".
 
Цитата
Michael_X пишет:
Вот, собственно, для этого методика и предлагалась - дабы дать предпосылки к тому, чтобы вы задумались и определили приоритеты Шутливо
Михаил, ты не прав. при выборе любого ПО на 1 месте всегда будет требование бизнесс процессу, удобство использования, цена, и т.п. безопасность далего и глубоко. Подход к выбору ПО основываясь ТОЛЬКО на информации по уязвимостям утопичен и в реальной жизни не применим.

Да и я вспоминаю твою статью, там был один критерий опасности - "Критичность". Такой подход уже давно никого не устраивает. Где то недавно на секлабе новость была что Symantec и др. собираются унифицировать параметры по которым определяется критичность уязвимости, их будет 5-6 штук. И это только критичность. А безопасность ПО кроме критичности это еще быстрота реагирования на дыру, практическая возможность эксплуатации и т.п. еще штук 10 параметров. Вот если бы в твоей статье были учтены все эти векторы, ее еще можно было назвать полезной. Только зачем тут статья? Тут нужен CRAMM или ПО от Медведовского. Они с этой задачей спрявятся намного лучше твоих формул.
 
Эх, ещё бы средство для сканирования мозгов админам, на предмет обнаружения дыр, и автоматическое средство для установки заплат на эти дыры. Ну а о патче исправляющем баги в ДНК начальства, вообще можно только мечтать...
 
Цитата
2NC.
1. Не надо оскорблять собеседника, тем более не зная его, можно попасть в неловкое положение. "Passive OS Fingerprinting (OSFP) is a method for passively detecting the operating system of a remote host based on certain characteristics within that host's TCP SYN packets. This information can then be used as criteria within filter rules." RTFM .... В любом случае Алексей Лукацкий прав (в ответе мне) - хост всегда может определить факт сканирования его автоматическим (!) средством.
Разве я оскорбляю? Толку от того,что определили, что производилось сканирование? Я рассматриваю с практической точки зрения. Определив открытые порты-можно выбирать тип атаки. Это одно.Во вторых-сканирование портов не является криминальным действием. Тысячи если не миллионы попыток сканирования происходят в Инете,и главное,не сам факт сканирования,а факт обнаружения портов с соответственно "повешенными" на них службами.. Толку от простого сканирования,если за этим не происходит ничего?.. :| и еще..Почему только SYN-пакеты? Я говорил и об аск - пакетах..Как с ними быть?
 
2NC
1. В pf интегрировали http://kerneltrap.org/node/770 (еще в 2003 г.) технологию пассивного fingerprint поэтому можно написать просто block from any os nmap. Но это не волшебное средство  - вот сигнатуры в pf0:
1024:64:0:40:.:.:-*NMAP:syn scan (1)
2048:64:0:40:.:.:-*NMAP:syn scan (2)
3072:64:0:40:.:.:-*NMAP:syn scan (3)
4096:64:0:40:.:.:-*NMAP:syn scan (4)

1024:64:0:60:W10,N,M265,T,E:P:-*NMAP:OS detection probe (1)
2048:64:0:60:W10,N,M265,T,E:P:-*NMAP:OS detection probe (2)
3072:64:0:60:W10,N,M265,T,E:P:-*NMAP:OS detection probe (3)
4096:64:0:60:W10,N,M265,T,E:P:-*NMAP:OS detection probe (4)

1024:64:0:60:W10,N,M265,T,E:PF:-*NMAP:OS detection probe w/flags (1)
2048:64:0:60:W10,N,M265,T,E:PF:-*NMAP:OS detection probe w/flags (2)
3072:64:0:60:W10,N,M265,T,E:PF:-*NMAP:OS detection probe w/flags (3)
4096:64:0:60:W10,N,M265,T,E:PF:-*NMAP:OS detection probe w/flags (4)
Для того чтобы бороться с запросами типа ACK - применяйте нормализацию http://www.icir.org/vern/papers/norm-usenix-sec-01-html/index.html.
 
Цитата
Michael_X пишет:
А вы не считаете, что вероятность её сноса будет в значительной степени зависеть (хотя и не только от этого) от уровня критичности уязвимости

 Ну мне критичность в данном случае совсем не важна. Есть вероятность. Нулевая, так рыпаться не буду. Не нулевая - начну рыпаться в зависимости от критичности.

Цитата
Michael_X пишет:
Вот, собственно, для этого методика и предлагалась - дабы дать предпосылки к тому, чтобы вы задумались и определили приоритеты

 Ну свою точку зрения я еще тогда высказал ;-)  Методика говорит только о защищенности прошлой версии, но никак не новой.
 
То Алексей Лукацкий.

и все же не согласен с карантином. Ещё раз подчеркиваю - независимые компании они хоть и партнеры, но они не зависимые.

А управлять их поведением - это навязывание. Ну и что что они с нашей точки зрения не соотвествуют уровню, они то в этом проблем не видят. Если как вы пишите - то получится куча карантинных зон (у каждого, и для каждого) и кто оплатит? (вот вы говорите что крышу  чините, ну и что есть у вас "карантинная" кровать для прораба который под хмелем на работу явился - нет, как же так - теория таки разошлась с практикой....)

Это раз.

Второе, обработка информации может происходить и у партнеров. То есть они к нам не лезут, мы им отдали часть информации на обработку (ну тот же аутсорсинг). И все (ну готовят они вам листы для крыши опять таки в "нетрезвом" виде, но в мастерской, и что .... ). Применив сканер мы сможем узнать как у них хорошо в плане безопасности, и какова вероятность что наши конкуренты уже "получили" нашу информацию от наших партнеров. А без сканера как? Пойдем и спросим их? Так они нам ведь честно и искренне скажут - все в порядке.

.".и тысячи компьютеров в сети уже..."  хорошо, накопят опыт напишут свои хвалебные статьи, рекомендации и комментарии, тогда и будем обсуждать - так сказать на практическом примере. ;)
А то как то минусы совсем укрылись под осенней листвой, потом снегом заметет, забудется, а весной оттает - глядишь а там взошло то чего совсем не ждали... - Извините за лирику.

А про надежность, я тоже хотел вставить - теория надежности это не только в плане надежности (как показателя системы), а в плане накопленного научного опыта, и почему бы его не применять, раз уж ищем оптимум у системы.
 
to Алексей Лукацкий

Ну да  в понедельник патч вышел, в пятницу таки установили... а потом читаем в следующий понедельник... Microsoft предупреждает о возможных проблемах после установки MS05-051, к примеру.... (а суббота и воскресенье... ну что делать - 2 из 7 такое бывает).

Это к тому - что смысл сканера в данной цепочке не понятен... остался. Если ставить все патчи - то система установки сама это сделает и на всех машинах, по расписанию (ну или не все - а те которые нужно из допущенных).

Если вязать сюда сканер то получается только ради ОДНОГО - сканер обнаружил - сразу поставили.... И никак по другому.
А если сразу поставили, то без тестирования на целевой системе.... (а её конфигурация чуток - на 0,07 % отличается от тестированной тем же MS) вот и прихлопнули машину, с известной вероятностью..

Тестировать же каждую заплатку... на каждой системе.... в условиях малого, среднего бизнеса - NOT REAL.

А если натянули патч партнерам - то "бахнули" не свою машину - а чужую, во они обрадуются.... прибегут прям с тренировки скажем по хоккею, гольфу, или боксу и будут доказывать свою правоту...

Другое дело, обнаружили уязвивость - блокировали её FW или другим средством, именно блокировали, то есть поставили стеночку между системой и возможным источником атаки, вот тут получается более красиво. На прямую уязвимость не проходит, да и обход стеночки тоже время и средства, а патч - выйдет, потестируется и плавно натянется в отведенное на то время (а не в момент осуществления транзакции). Это как вариант. Опять таки вероятность срабатывания уязвимости по времени можно считать, вы же писали про систему у которой 100 уязвимостей - а она не взломана.

Так что аналитический обзор наверное можно расширить до скажем исследовательского (по моему скромному мнению), тема интересна, вопросы затронутые в ней актуальны. Судя по отзывам - которые вполне конструктивны критика может быть учтена и переработана. Осталось дело за малым...

Удачи в работе.
 
"Михаил, ты не прав. при выборе любого ПО на 1 месте всегда будет требование бизнесс процессу, удобство использования, цена, и т.п. безопасность далего и глубоко. Подход к выбору ПО основываясь ТОЛЬКО на информации по уязвимостям утопичен и в реальной жизни не применим."

А я и не пытаюсь с этим спорить. Я не говорю, что оценка защищённости системы - это решающий фактор в жизни или смерти ИС, хотя и считаю его одним из основных. Есть необходимость в создании метода оценки этого самого фактора (и только лишь его пока) на основе теории вероятности.

"Да и я вспоминаю твою статью, там был один критерий опасности - "Критичность". Такой подход уже давно никого не устраивает. Где то недавно на секлабе новость была что Symantec и др. собираются унифицировать параметры по которым определяется критичность уязвимости, их будет 5-6 штук. И это только критичность. А безопасность ПО кроме критичности это еще быстрота реагирования на дыру, практическая возможность эксплуатации и т.п. еще штук 10 параметров. Вот если бы в твоей статье были учтены все эти векторы, ее еще можно было назвать полезной."

Я несколько раз тогда говорил, возможно добавление и других параметров, влияющих на оценку... Я лишь предложил общую идею оценки на основе теории вероятности (хотя, не спорю, тогда метод был ещё сырой, но сейчас он подвергся сильной модификации на основе услышанной конструктивной критики, хотя сам принцып остался преждним).
Спасибо за конструктивную критику  ;)
 
2Алексей
" Методика говорит только о защищенности прошлой версии, но никак не новой."

Алексей, это не просто прошлая версия... это один из факторов статистики, который позволяет применять методы теории вероятности.  ;)
 
Представляю себе сервер, например, МТС, на который сработал ложно сканер и как итог клиенты не могут получить доступ к серверу :-)

Сколько раз видел как все известные сканеры ложно срабатывали.
 
Цитата
РНТ со своим «Стилетом», ЦБИ с «Ревизором Сети», Элвис+ с «Заставой-Инспектором»  

И другие варианты нессуса :-))
 
:)
Цитата

Создано: 16.10.2005 18:53:19
Имя  Цитировать



2NC
1. В pf интегрировали http://kerneltrap.org/node/770 (еще в 2003 г.) технологию пассивного fingerprint поэтому можно написать просто block from any os nmap. Но это не волшебное средство - вот сигнатуры в pf0:
1024:64:0:40:.:.:-*NMAP:syn scan (1)
2048:64:0:40:.:.:-*NMAP:syn scan (2)
3072:64:0:40:.:.:-*NMAP:syn scan (3)
4096:64:0:40:.:.:-*NMAP:syn scan (4)

1024:64:0:60:W10,N,M265,T,E:P:-*NMAP:OS detection probe (1)
2048:64:0:60:W10,N,M265,T,E:P:-*NMAP:OS detection probe (2)
3072:64:0:60:W10,N,M265,T,E:P:-*NMAP:OS detection probe (3)
4096:64:0:60:W10,N,M265,T,E:P:-*NMAP:OS detection probe (4)

1024:64:0:60:W10,N,M265,T,E:PF:-*NMAP:OS detection probe w/flags (1)
2048:64:0:60:W10,N,M265,T,E:PF:-*NMAP:OS detection probe w/flags (2)
3072:64:0:60:W10,N,M265,T,E:PF:-*NMAP:OS detection probe w/flags (3)
4096:64:0:60:W10,N,M265,T,E:PF:-*NMAP:OS detection probe w/flags (4)
Для того чтобы бороться с запросами типа ACK - применяйте нормализацию http://www.icir.org/vern/papers/norm-...index.html.
Во сколько (в денежном эквиваленте) такое обойдется средней фирме? И пойдет ли руководство на подобный шаг?
Ни один директор на подпишет такие расходы.Он предпочтет сменить сисадмина.. :)
Страницы: Пред. 1 2 3 4 След.
Читают тему