информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Простое пробивание рабочего/провайдерского... 
 400 уязвимостей в процессорах Snapdragon 
 Яндекс неуклюже оправдался за установку... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / sysadmin
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
имхо 27.01.05 01:45  Число просмотров: 1682
Автор: whiletrue <Роман> Статус: Elderman
<"чистая" ссылка>
имхо, такой контроль будет работать до тех пор, пока сотрудники не знают, что эта система установлена. Если же они узнают, то найдут способы анонимно сливать инфу.

> Что, например, можно сейчас:
> Извлечь из письма приаттаченный .rar, распаковать его
> (может быть даже попытавшись угадать пароль по словарю или
> перебором до небольшой длинны. или просто заблокировать
> письмо с запароленым архивом), найти в архиве .doc файл, а
> в нем - подстрочку, подозрительно напоминающую номер
> банковского счета, или телефонный номер клиента, увязать
> это с тем, что данный отправитель в данное время на данный
> адрес не имеет права отсылать такую информацию и принять
> меры - это можно.
> Со стеганографией, особенно качественной - уже хуже. Но в
> области защиты информации "гонка вооружений" давно идет и
> по всем фронтам. Ни антивирус, ни файрвол, ни IDS в своей
> области не работают идеально, но развиваются в соответствии
> с растущими требованиями.
>
> Мне кажется, что блокирование писем - не должно быть
> основной мерой. Во-первых, как вы уже заметили, нельзя
> полагаться, что обхитрить фильтр невозможно (особенно, если
> "хитрящий" имеет обратную связь: Отправил письмо - оно не
> дошло. поменял, отправил - дошло.). А во-вторых, сложные
> фильтры могут быть написаны не очень аккуратно, и давать
> сбои (false positives).

Еще можно послать фотку другу, в которой вотермарком зашировать секретную инфу...

> Мы обычно рекомендуем если и блокировать, то только самые
> грубые нарушения. А основная мера - просто записывать
> почту. Или только подозрительную, или всю (про
> подозрительную, при этом, можно извещать админа). В
> результате, на стороне защитников есть эффект
> неожиданности. Если уж мы узнаем, что Иван Иваныч

В этом плане да, удобно Иван Иваныч облажался и отправил инфу [почти] открытым текстом, мы получили извещение - все классно. Но это все работает опять таки, пока сотрудники не начнут шифроваться, а как начнут - то от такой системы будет только вред, так как мы уже будем на нее полагаться, хотя бы потому, что заплатили за нее денег. Более того, в этом случае еще возможно организовать подставу.

> конкурентам данные сливает, так и хорошо, порадуем СБ,
> пусть оперативную игру проведут, пусть теперь наш И.И.
> конкурентам дезинформацию сливает, компенсирует ущерб. Или
> просто планы фирмы можно скорректировать, с учетом потерь.
> Ну или уволить-расстрелять - это по вкусу.
>
> > Вывод: посылаемая почта при помощи
> > веб-интерфейса через программу фильтрующую почту не
> пройдет
> > вообще.
> Я не столь категоричен в этом отношении. Сейчас мне не
> известны средства, которые бы на практике позволяли
> перехватывать вебмейловскую почту, хотя в теории -
> перехвать http траффик сабмита формы (зная типичную
> структуру формы для mail.ru, например) - не так уж и
> сложно. SSL усложняет работу, но можно либо запретить его,
> либо проксировать его (скармливая клиентскому браузеру наши
> ключи для шифрования, а не оригинальные). Конечно, пользы
> от такого SSL будет не так уж и много, но в принципе,
> задача решаема. Есть куда развиваться. :-).
>
> А пока же, "для экономии трафика и рабочего времени", лучше
> просто закрывать (или протоколировать) доступ на вебмейлы,
> и требовать использования smtp и pop3, хоть с того же
> сервера бесплатной почты. Мы сейчас думаем о создании своей
> большой базы вебмейлов. Конечно, она никогда не будет
> полной, но зато можно выпустить приказ по фирме о
> запрещении использования вебмейлов, обнаруживать нарушения
> (сотрудник ведь не знает, есть ли его вебмейл сейчас в
> базе, и не появится ли он там через час) и наказывать. У
> сотрудника "всего одна жизнь" в этой игре. Один раз уволят,
> при грубом нарушении - больше нарушений не будет.

Тогда надо отсеивать не только вебмылы, но и форумы и чаты, или же вообще запретить POST запросы :)

>
> > Нет такого опыта, увы.
> Кстати. А профессиональная деятельность не исключает такой
> опыт? Если не исключает, то почему не было? Парадоксально -
> недавно нашел исследование, так почти все опрошенные (ранга
> CIO, CSO и около того), признают, что имоченьсильно
> требуется контролировать почту, но, как правило, просто не
> знают средств для этого.

имхо, полезнее нанять специального человека, просматривающего вообще всё.
<sysadmin> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach