18 Сентября, 2013

Четыре рубежа

InfoWatch
Предположим, вы проектируете большую информационную систему, в которой будет циркулировать конфиденциальная информация. Если б система была не очень большой, вы могли бы ограничиться одной линией обороны – просто свести к ничтожно малой величине вероятность утечки.
       

Однако, как мы знаем , чем больше пользователей, тем ближе к единице эта вероятность. Поэтому крупные ИС должны иметь и вторую линию обороны – средства выявления утечек. Надо не только предотвращать, но и закрывать уже образовавшиеся дырки. Утечки делятся на разовые и длящиеся. Последние опасней  и на них не распространяется принцип "слово – не воробей"; чем раньше перекроем, тем больше сэкономим денег.

Но в больших, по-настоящему больших системах (например, целое министерство с 89 управлениями и 100500 районными отделами) утечки не только обязательно будут (вероятность = 1), но и будут подчиняться статистике. Поэтому нужна третья линия обороны – подсистема сбора доказательств нарушений. То есть, мы не только сторожим информацию, не только выявляем и перекрываем состоявшиеся утечки, но и автоматически собираем юридически значимыеданные для наказания виновных. Эта третья линия позволит нам задействовать ещё один механизм защиты – страх наказания.

Теоретически возможна и четвёртая линия защиты от утечек. Мы должны сделать так, чтобы утекшая информация не вызывала доверия у противника. Чтобы её трудно было перепроверить. Чтобы вражеский агент, если уж смог слить какие-то данные, то не смог бы доказать своему начальству их валидность.

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

или введите имя

CAPTCHA
Антон
24 Сентября, 2013
Четвертый базируется на третьем вполне логично
Третий внедряет статистически значимый "псевдошум" либо в любые данные (но при этом другие соседние модули должны уметь однозначно убирать шум с чистых данных на своем входе), либо в сопутствующие процессу вывода данных носители - печатные символы с "битыми" по алгоритму пикселями и т.п. Но при этом, шум для четвертого уровня должен подчиняться логике алгоритма формирования: Например, третий уровень из исходной верной таблицы: A B S 1 2 3 2 5 7 4 5 9 4 1 5 создает дезу: A B S 1 3 4 3 4 7 4 5 9 5 0 5 по правилу деза:=A+T 0 1 1 -1 0 0 0 0 0 -1 0 0 но при этом сохраняется не только логика, но арифметика общей формулы счета A+B=S (которую математики с обеих сторон как-то вывели независимо друг от друга), а экспериментальные данные одни у других крадут.
0 |