• NetBIOS в руках хакера
    –1
    Разница NetBIOS на разных версиях Windows наблюдалась только на 2000 и более новых. На 2000 мы имеем null-session (как на самом первом скрине c Linux), с единственным отличием от Linux — win2000 сообщит свой MAC, тогда как Linux вернёт 00:00:00:00:00:00. Так, более глубокое исследование различий не производилось.
    Что касается рекомендаций — всё это не уязвимости, а лишь сбор безобидной информации. Вся получаемая информация не является конфиденциальной. И даже если у вас Null-session, и злоумышленник установил, что вы в домене и у вас много сетевых карт, в случае если у вас стойкий пароль и установлены все обновления — вам не чего бояться. Однако NetBIOS может использоваться для атаки, как это делают с помощью инструмента Responder. Но это уже отдельная статья…
  • Подбираем пароли с помощью Google Chrome
    0
    Согласен. Капча на данный момент лучшая защита от автоматического перебора, но не от ручного. Правда встречается капча далеко не так часто…
  • Подбираем пароли с помощью Google Chrome
    0
    Вроде не было… А что вы имеете ввиду?
  • Анализ обнаружения обфусцированных вирусов мобильными антивирусными приложениями на платформе Android
    +1
    Настоящая статья затрагивает только вопрос детекта обфусцированных приложений и не раскрывает полной сути исследования, которое было значительно шире. С обобщенными результатами исследования можно ознакомиться на сайте securitylab http://www.securitylab.ru/analytics/483120.php, там кстати приводятся имена антивирусов, справившихся с проверкой.
  • Анализ обнаружения обфусцированных вирусов мобильными антивирусными приложениями на платформе Android
    +1
    нет, не планируем, разрабатывали для тестирования
  • НЕтехнологические проблемы защиты от утечек. Практика полевого инженера
    0
    50 дверей: ну если у вас уже 50 дверей то действительно поздно пить боржоми… В таком сценарии DLP поможет хотя-бы вам качественно ценить с какой скоростью у вас воруют данные…


    Риторика и метафоры, это, конечно, мощный инструмент убеждения, но давайте попробуем вернуться к сути. В инфраструктуре каждого предприятия используется значительное количество ПО, каждое со своими ошибками, уязвимостями и т.п. То есть это не у нас 50 дверей, это у всех так. А про оценить «с какой скоростью воруют» я даже комментировать не буду, уже много раз повторил, что системы внедряются, работают, обнаруживают и предотвращают, и это не только глянцевая отчетность производителей, но и моя личная практика.

    Что касается аудита — во-первых, это та самая «еще одна дверь». Во-вторых, статистические методы работают только в части случаев. И не вскрывают подробности утечки. И не могут служить в качестве доказательной базы. В целом — не лучший инструмент в деле борьбы с утечками, хотя своя ниша у него есть и в качестве составляющей комплекса он вполне работает.
    Ну а доступ к чувствительным данным у системы — минус, безусловно. Но этот доступ, так или иначе, уже есть у многих систем, а главное — у пользователей. И я не склонен рассматривать еще одну систему как значимую угрозу безопасности.
    Тем более, что для большинства компаний наибольшую угрозу представляют как раз «внутренние утечки», организованные, вольно или невольно, силами сотрудников. А вовсе не взломы и использование уязвимостей ПО, о которых Вы столько пишете.
  • НЕтехнологические проблемы защиты от утечек. Практика полевого инженера
    0
    Наверное, действительно не согласимся.
    Вы мне говорите, что пятьдесят две двери хуже, чем пятьдесят одна, а я Вам говорю, что хуже, безусловно, но не настолько, чтобы отказываться от нужной полезной двери (особенно если сравнивать в процентном отношении).
    А вот «все равно обворуют» я не писал, писал обратное, и очень удивлен откуда вдруг такая трактовка моих слов взялась (равно как остальные трактовки моих слов в Вашем последнем комментарии). Так что да, мы наверняка работаем в разных областях.

    По поводу аудита — в целом, понятно. Непонятно какие именно средства предлагается использовать для «безопасного» аудита, чтобы не городить «еще одну дверь». Ссылка по этом вопросу ясности не вносит.
    То есть я, безусловно, могу предположить, средствами каких систем это можно сделать, но, во-первых, мне не очень понятно, чем они будут принципиально лучше с точки зрения ИБ, чем DLP, а во-вторых, там все очень непросто с эффективностью — особенно если сравнивать с DLP-системами.

    Ну и — нет, кража отнюдь не всегда сопровождается аномальной активностью и у меня есть достаточное количество живых кейсов, когда все происходило строго в рамках повседневных обязанностей и не было значимых отклонений от типичного профиля поведения. Но это отдельная большая тема.
  • НЕтехнологические проблемы защиты от утечек. Практика полевого инженера
    0
    Ок, продолжим.

    — Фундаментальная проблема DLP №1 — чтобы что-то найти надо знать что искать. Ваш DLP получит доступ к вашим «секретным» данным.

    Безусловно, DLP-система имеет доступ к секретным данным. Часто в ней самой хранятся какие-то данные, относящиеся к конфиденциальным. Но я не вполне понял из Вашей формулировки, в чем здесь проблема, поэтому попробую пофантазировать. В том, что из DLP-системы проще воровать данные? Так ее, в общем-то, просто надо грамотно настраивать и защищать — так же, как любое хранилище, содержащее эти данные. Ничего принципиально нового в список угроз при этом не привносится.

    Фундаментальная проблема DLP №2 — чтобы что-то найти надо чтобы вам никто не мешал это делать.

    Про шифрование трафика уже писал выше, обсудим endpoint.
    Опять же, не очень понимаю, о чем речь. Агент DLP-системы на конечной точке — адекватно установленное легитимное ПО, которое даже не нужно добавлять в исключения антивирусов и прочего защитного ПО. Я не видел конфликтов DLP с антивирусами несколько лет — все ошибки и конфликты давно отработаны и исключены совместными усилиями вендоров. Что же касается уязвимостей самой DLP-системы — то тут смотрим п.1, систему нужно защищать так же, как остальные системы, сопряженные с обработкой конфиденциальных данных. Ничего такого исключительного.

    Фундаментальная проблема DLP №3 — проблема черного ящика.

    Как было справедливо отмечено, ошибки архитектуры, реализации и имплементации присущи любым системам — в том числе, от изветных мировых производителей с прекрасной репутацией. Причем это относится к открытому коду, к закрытому коду, к коду прошедшему аудит — в любом случае будут какие-то уязвимости. Однако, как мне кажется, это не служит причиной отказаться от использования ПО в целом. Да, были ошибки и уязвимости — однако продукты Symantec, Palo Alto, FortiNet, Cisco и т.п. продолжает пользоваться огромным спросом. Потому что получаемое с их помощью преимущество превышает потенциальные риски.

    Так же и DLP-системами — безусловно, есть определенные риски ИБ с ними связанные. Однако эти риски не превышают рисков, связанных с использованием другого ПО (во всяком случае, не критично), а преимущества от использования велики.
    Кроме того, DLP-системы в подавляющем большинстве случаев функционируют внутри периметра предприятия, находятся под защитой специализированных средств и добраться до их уязвимостей — отдельная нетривиальная задача. И если все-таки это происходит, значит неадекватно отработали, в первую очередь, все остальные средства защиты и конфиденциальная информация в любом случае оказалась доступной злоумышленникам.

    Во всех остальных случаях вы привносите гарантированное ухудшение безопасности в надежде на гипотетическую надежду что-то, когда-то поймать… Как по мне — это неоправданный риск. Адекватной реализаций клиентов и плотным аудитом можно получить тот-же результат без ухудшения безопасности.

    За всю свою практику я никогда не слышал о взломе и утечке данных, реализованных через уязвимости DLP-системы. Зато я видел множество случаев, когда утечки при помощи DLP-систем были обнаружены и предотвращены. Так что на практике ситуация получается обратная — вместо «надежды на гипотетическую надежду что-то там поймать» есть стабильные результаты, а вместо «гарантированного ухудшения безопасности» безопасность почему-то не ухудшается.

    Ну и встречный вопрос — а что это за «плотный аудит» без применения DLP-систем, при помощи которого можно получить тот же результат? Какими средствами реализуется?
  • НЕтехнологические проблемы защиты от утечек. Практика полевого инженера
    0
    Что бы DLP работал вам в общем случае нужно для начала ослабить безопасность до уровня допускающего внедрение DLP — убрать шифрование с каналов связи, всунуть свой корневой сертификат на машины или сделать любую аналогичную глупость. Нельзя своими руками ослаблять «реальную» защиту в надежде что DLP чтонибуть поймает. Ваш DLP — потенциально дополнительный канал утечки…


    Ну, вообще-то это немного не так.
    Давайте немножко к азам вернемся.
    DLP-системы в простом случае (не будем пока касаться вариантов утечек путем кражи жесткий дисков, фотографирования монитора и т.п.) контролируют утечки в следующих точках: почта, web, конечные точки.

    Для контроля исходящей почты достаточно использовать SPAN-порт либо mail relay, никакая безопасность здесь не страдает при минимальной грамотности внедрения. В случае необходимости контролировать на предмет утечек еще и внутреннюю переписку (задача более редка и экзотическая, но встречающаяся) обычно используется агент на почтовом сервере — тоже никаких особенных ослаблений безопасности.

    Для контроля web, в частности, шифрованных соединений, безусловно, требуется использовать дешифрование трафика и MitM. Что, как бы, несколько ослабляет безопасность. Но, во-первых, именно как бы, а во-вторых и главных, такая дешифровка все равно используется безо всякого DLP. Делается это на proxy либо NGFW — для контроля доступа в интернет, запрет доступа к определенным категориям сайтов и т.п. Такие системы и механизмы традиционно внедряются задолго до DLP (либо, гораздо реже, одновременно — если это комплексное решение по защите доступа в интернет, защите почты и защите от утечек, как ForcePoint Triton, например). То есть, опять же, DLP-система ничего особенно нового в безопасность не привносит.

    Ну и контроль на конечных точках (рабочих станциях, ноутбуках, мобильных устройствах, терминальных серверах и т.п.) — это просто агент, такой же, как антивирус, средства контроля целостности и т.п. и точно так же не привносит ничего волшебного в ослабление безопасности. Причем именно этот метод является, на мой взгляд, самым эффективным способом контроля утечек, т.к. позволяет контролировать наибольшее количество потенциальных каналов утечки а заодно как раз оказывает наименьшее влияние на существующую инфраструктуру (хотя не всегда можно только им обойтись).

    Резюмирую: DLP-система не ослабляет никакую такую «реальную» защиту, а, наоборот, добавляет к ней еще один эшелон.
    Хотя, справедливости ради, я как-то из спортивного интереса придумал сценарий, когда DLP-система использовалась как инструмент утечки. Но это уже совсем экзотика, большое исключение из общего правила и притягивание за уши сопутствующих обстоятельств.

    Так что позвольте с Вами, как бы это помягче сказать, не согласиться.
  • НЕтехнологические проблемы защиты от утечек. Практика полевого инженера
    0
    Ну отчего же сразу шпионаж? Нет, не шпионаж, не телепатия, вообще ничего криминального.
    Есть техническая возможность отслеживать аномалии в поведении пользователя. Есть возможность сопоставить поведение пользователя с его служебными обязанностями и текущими рабочими активностями. Но если совсем по простому, то да — есть технические способы отследить намерение человека по тому, какой документ он открывает.

    Сразу оговорюсь — технологии эти не бесспорны, стопроцентной гарантии (как и любые другие технологии) не дают, для эффективной работы требуется активное участие человеческого мозга, но в целом это работает.
  • НЕтехнологические проблемы защиты от утечек. Практика полевого инженера
    0
    Это, безусловно, личное дело, как какую систему называть.
    Для меня вот есть ряд различий на уровне как идеологии, так и применяемых технологий, которые, на мой взгляд, все-таки позволяют развести DRM и DLP. Хотя, повторюсь, и цели применения этих классов пересекаются, и часть используемых механизмов.

    Вообще с DLP-системами много путаницы — к ним часто относят смежные (и даже не очень смежные) классы решений: DRM, системы контроля доступа к информации, системы контроля персонала, системы контроля съемных носителей и т.п. А с учетом того, что в новых версиях систем используются механизмы, позволяющие их на самом деле относить к нескольким классам одновременно, ситуация еще больше усложнилась.
  • НЕтехнологические проблемы защиты от утечек. Практика полевого инженера
    0
    Ну, вообще-то, DRM это другой класс систем, хотя и смежный.
  • НЕтехнологические проблемы защиты от утечек. Практика полевого инженера
    +1
    А слышал ли автор, что современные деньги 90% времени находятся в виде информации, в виде этих самых данных? И что первые, кто внедряют DLP — это банки? В чем подвох-то?

    Автор даже внедрял DLP-системы в банках.

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

    Среди российских продуктов пока еще нет DLP-систем, готовых для «продажи из коробки». И не скоро еще будет, т.к. нет спроса

    Есть спрос. Запросы есть постоянно, продажи растут, и будут расти. Как же это — нет спроса?

    а спроса нет потому, что правовая база так и не работает.

    Ну, спрос, положим, меньше, чем мог бы быть, все-таки не поэтому. Есть масса заказчиков, которым правовая база не только не нужно, но и мешает. И есть вендоры, которые идеологию и технические особенности своих систем на этом строят.
    Хотя, конечно, с юридической стороны тема пока еще очень слабо проработана. Другое дело, что даже существующая правовая база вполне позволяет применять эти системы и использовать собранные с их помощью данные в качестве доказательной базы в суде — прецеденты есть, и их все больше. Причем правовая база совершенствуется, и совершенствуется не без помощи производителей DLP-систем и тех заказчиков, которые эти системы используют.

    А импортные недостаточно гибки для «прогибания» под российскими реалиями и вообще они (импортные) теперь «за бортом», в соответствии с линией партии.

    А вот это да. Есть такое. Безусловно, импортные решения тоже внедряются, на за последнюю пару лет количество таких внедрений критически уменьшилось.
  • НЕтехнологические проблемы защиты от утечек. Практика полевого инженера
    +1
    Приятно видеть, что кто-то внимательно прочитал статью!
  • НЕтехнологические проблемы защиты от утечек. Практика полевого инженера
    +2
    Потом выяснилось, что один из менеджеров просто ЗАПОМИНАЛ реквизиты топ клиентов и за несколько недель собрал почти полную базу.

    Соглашусь, от таких случаев DLP-система не спасает. Но есть еще масса случаев, когда она как раз будет спасать. Совсем не все можно унести в голове, к счастью.

    Часто бывают комичные ситуации. DLP стоит, главбуху базу унести не дает. Главбух идет жаловаться руководству, которое потом натягивает отдел ИБ и дает распоряжение обеспечить возможность копирования базы главбухом.

    Распространенная беда. Только это не проблема и недостаток DLP-системы.
    От намеренного воровства такие системы не спасут. Потому, имхо, нет никакого смысла вгрызаться в траффик, ставить прослушки скайпа и заниматься перехватом документов при печати.

    Вообще-то часто спасают. Да, безусловно, есть способы обмануть любую такую систему — даже без фотоаппарата, запоминания и т.п. Но, как сказал классик, «никогда не следует недооценивать предсказуемость тупизны». Удивительно, насколько распространена ситуация, когда злоумышленник точно зная, что на предприятии применяются средства обнаружения и предотвращения утечек, тем не менее, тупо копирует нужные материалы на флэшку. А вот случаи настоящей хитрости и глубоких познаний в вопросе кражи информации — это как раз, скорее, исключение.

    Это все лажа, так как сфоткать на телефон можно абсолютно любую информацию. При желании можно даже записывать в блокнот.

    Есть способы борьбы и с такими фокусами. Хотя, как я писал выше, это часто просто не нужно.

    Что теперь, отбирать телефоны на входе и устраивать всем анальный досмотр на КПП? Бред же.

    Многие так и делают (с поправкой на «анальный досмотр»). Но можно и без этого.

    Проблем от такого подхода просто неимоверное количество и админить инфраструктуру DLP должно большое количество человек. Просто непозволительная роскошь.

    Это, мягко говоря, не так. В большинстве случаев это работает по схеме «1 администратор + 1 офице ИБ», и все прекрасно справляются. Причем контроль и администрирование DLP-системы у них даже не основной вид деятельности.

  • НЕтехнологические проблемы защиты от утечек. Практика полевого инженера
    +2
    Вы главное помните хотя бы пару аксиом)

    1. DLP — это не защита от утечек информации, а защита от СЛУЧАЙНЫХ утечек информации.
    2. Исходя из п.1 — ваши данные всё равно утекут, когда придёт срок.


    Это не аксиомы. Это мнение.
    Не говоря о том, что аксиома не может вытекать из другой аксиомы по определению.

    А если серьезно — не соглашусь.
    Безусловно, ни одна система защиты не даст стопроцентной гарантии отсутствия утечек — если не доводить идею до абсурда и не включать в комплекс технических и организационных мер, каковым является любая нормально внедренная DLP-система, пропуск сотрудников на рабочее место голыми после всестороннего досмотра и их расстрела по завершении рабочего дня.

    Но если DLP-систему применять грамотно, она помогает снизить риски утечки информации до приемлемого уровня. И результат будет зависеть от того, насколько технически продвинутая система применена, насколько грамотно ее внедрили и настроили и насколько грамотно эксплуатируют.

    То есть да, соглашусь — результат DLP-система дает не абсолютный, но, тем не менее, дает.
  • НЕтехнологические проблемы защиты от утечек. Практика полевого инженера
    +1
    Простите, но я не заметил в описании проблемы фактов воровства.

    Статья получилась не столько о проблемах, которые решают средствами DLP-систем, сколько о проблемах, которые возникают при внедрении этих систем. Поэтому здесь очень мало про факты воровства, халатности, коррупции, про то, как одно отличать от другого и т.п. Возможно, следующая статья по теме DLP будет про это, тогда поподробнее и рассмотрим эти вопросы.

    По поводу базы клиентов — планируете чистить память людям после увольнения?

    Согласен, пример не очень чистый. Хотя много таких баз, которые не запомнишь. Другое дело, что клиентскими базами, безусловно, список защищаемых данных не ограничивается.

    Но — да, я соглашусь. Как бы это не шокировало, у DLP-систем действительно есть ограничения.
  • НЕтехнологические проблемы защиты от утечек. Практика полевого инженера
    0
    Почему-то только в разработке нашелся хаб «Информационная безопасность», пришлось писать сюда. Хотя, конечно, к разработке статья имеет очень слабое отношение.
  • Ищем уязвимости с помощью google
    0
    Прекрасно, пробуйте снова, например dorks.sh ghdb –c 3
  • Ищем уязвимости с помощью google
    0
    Данная ошибка просто означает что страница не загрузилась. Причина – интернет соединение, либо временная недоступность ресурса (строки 363-365).
  • Ищем уязвимости с помощью google
    0
    Наиболее часто встречаемые пожалуй из категории «Error messages». Так же удобный собственный дорк – с рисунка 8, на все необычные типы файлов, достаточно часто находит инфу.
  • Easy Hack: Java application
    0
    Ага, статья совсем «для начинающих». Название, на мой взгляд, полностью это отражает — «Easy Hack».
    Этот метод патча ни в коем случае не претендует на универсальность. Он даже не способен обойти простейшие механизмы защиты, как вы правильно заметили.
    Однако, этот метод работает очень во многих случаях — далеко не все бинарники обфуцируют.
    Думаю, эта инструкция пригодится людям далёким от java, которые не хотят лезть в байткод и разбираться в java-машине
  • Easy Hack: Java application
    0
    Да, разумеется — существует много путей достижения цели.
    Но когда справляется JAD, зачем усложнять себе жизнь?