Category: происшествия

Category was added automatically. Read all entries about "происшествия".

white

Как можно незаметно потрошить банкоматы - часть 2.

Начало этой прекрасной истории мы публиковали тут.



Есть достаточно широко применяемая специалистами утилита KDiag, служащая для диагностики банкоматов марки Wincor Nixdorf. Одна из ее функций  – тестирование работоспособности механизма выдачи денежных средств. Условие запуска – банкомат в этот момент должен находиться в тестовом режиме, а створки сейфа должны быть открыты.

Collapse )
white

Утекай: как минимизировать негативные последствия утечки информации (ч.1)

«Все американские компании делятся на две категории: те, у которых были инциденты ИБ, и те, кто просто об этом еще не догадывается»
Джеймс Коми, директор ФБР


В 2013 году у 43% всех компаний США хотя бы раз случалась утечка информации.  Симптоматично, что по данным InfoWatch за тот же период, Россия  занимает вторую строчку в глобальном рейтинге утечек - как раз после Штатов.

Эксперты знают, что 100% безопасности не существует и инциденты случаются даже в тех компаниях, где вопросам ИБ уделяется самое пристальное внимание. Утечка данных – это не вопрос о том «как?», это вопрос о том «когда?». Поэтому в этот раз мы зайдем с другого конца и расскажем, как действовать, чтобы исправить допущенные ошибки и не совершить при этом новых.
Collapse )
white

Опасное сближение

Бесконтактные платежи на технологиях группы NFC предназначены для небольших транзакций типа оплаты проезда или расчёта за мелкие покупки. В них риск из-за недостаточности авторизации компенсируется незначительностью суммы. Ведь авторизация со стороны плательщика состоит главным образом в том, что устройство/карта близко подносится ко считывателю. Факт близости одного к другому рассматривается как санкция пользователя.
   

Очевидно, что близость бывает не только по обоюдному согласию. Кроме того, её можно имитировать при помощи усиливающей сигнал аппаратуры.

А мелкость суммы – это как раз то, что кардеры давно уже эксплуатируют в качестве основной своей защиты. Вменяемый мошенник не пойдёт на преступление, если вероятность начала расследования существенно отличается от нуля. Даже вероятность 1-2% для него слишком высока, потому что воровать приходится многократно. При повторении попыток суммарная вероятность очень быстро стремится к единице. Приемлемое решение – красть понемногу, так, чтобы банку невыгодно было проводить расследование инцидента, а проще было бы не заметить, списать или взыскать с продавца.

Бесконтактные платежи именно на это и ориентированы – много плательщиков, мелкие суммы, низкие издержки. Последнее подразумевает, что затраты на расследование инцидентов также должны быть низкими. То есть инцидент выгоднее не заметить, чем учинять разбирательство. Предположим, вы строите платёжную систему. Разумеется, закладываете в свои издержки работу службы ИБ. Если хотите быть в прибыли, то рабочего времени у нанятых вами ИБшников хватит на расследование, скажем, 1/5 000 000-й части всех транзакций. Чаще – нельзя. Все остальные подозрительные или обжалованные пользователями транзакции придётся оставить в силе или откатить без разбирательства. Но если их будет больше, чем 1/100 000-я доля, вы начнёте терять на этом деньги. Искусство мошенника заключается в том, чтобы уложить все хищения в указанный промежуток – между 1/100 000-й и 1/5 000 000-й долями.

В настоящий момент бесконтактных мошенников удерживает то, что затруднительно подключиться к системе в качестве мерчанта – субъекта, принимающего платежи. Таковых пока очень мало. Следует подождать 2-3 годика. А потом – только хардкор, только шапочка из фольги.

white

Дембель неизбежен

О, сколько нам открытий чудных готовит просвещенья дух! А ещё внедрение DLP-систем. Оно никогда не обходится без удивительных открытий для начальства. Буквально каждый проект выявляет такое, чего директор на своём предприятии даже не подозревал. Рассказали об одном таком.
сержант строит пользователей  

Свежепоставленная DLP мониторила, в частности, обращения к корпоративной БД, пытаясь найти в потоке SQL-команд аномалии, свидетельствующие об утечках. Аномалия не заставила себя ждать.

В одном из подразделений работали пять сотрудниц, которым вменялось вносить и редактировать записи в БД. Начальство подразумевало, что работа распределена между ними равномерно и обсуждало вопрос об увеличении штата до шести единиц. Замеры же показали, что ни о какой равномерности речи не идёт: 80% транзакций в базу были с аккаунта одной работницы, а 20% – с аккаунтов остальных четверых.

Сперва статистику истолковали превратно и заподозрили попытку слить базу. Но быстро выяснилась настоящая причина. Оказалось, в этом дружном коллективе установлена классическая дедовщина, хотя и в женском исполнении. Самая молодая выполняла 80% работы подразделения, поскольку, как ей объяснили, у старших товарок стоят более серьёзные и более ответственные задачи. Таковыми задачами при расследовании инцидента оказались переписка в "Одноклассниках", питие чаёв и курение в курилках.

Одно лишь сокращение лишних "дембелей", если бы оно произошло (рассказчик просто не в курсе их дальнейшей судьбы), окупило бы половину стоимости внедряемой системы. А ведь впереди были ещё настоящие утечки.

white

Интернет диких вещей

       
Я вам уже однажды напророчествовал, что главная опасность исходит не от прикладного ПО и не от системного, а от встраиваемого, оно же firmware. Потому что контроля за ним меньше. Вплоть до того, что иной раз вообще неизвестно о наличии в микросхеме какой-либо программы. А она там есть. И принимает решения. И решения эти, как следует из нижепроцитированного, затрагивают фундаментальные права человека:
«Автомобили "Camry" начали неоднократно проявлять норов и склонность к неуправляемому разгону... Суд штата Оклахома признал Toyota ответственной за инцидент шестилетней давности с присуждением полуторамиллионного штрафа. А специалисты в области embedded-программирования по окончанию судебного процесса получили возможность открыть данные об экспертизе прошивки злополучного контроллера дроссельной заслонки. И данные оказались далёкими от утешительных... "это позорный образец проектирования и разработки ПО"... "ошибки в firmware стали причиной аварии с тяжёлыми последствиями".»
Стандарты разработки и тестирования ПО, как оказалось, вообще не применяются для программ этого класса.

Рынок с большим трудом может регулировать качество firmware. Его производители, если и конкурируют, то исключительно по критерию цены. Отсутствие пользовательского интерфейса не позволяет конечным потребителям сказать своё слово. Как тут можно запустить рыночные механизмы – мне в голову не приходит. Запускать же в эту сферу контролирующие государственные органы – хочется ещё меньше.

Решение проблемы видится в недавно появившейся тенденции – переходе техники на универсальные ОС. И телевизор, и микроволновка, и снайперский прицел, и одноразовый рекламный вкладыш в журнале – всё это с успехом запускает внутри себя какой-нибудь проверенный годами Линукс. Системное и прикладное ПО вполне поддаётся аудиту, может быть сертифицировано проверено, а также заменено и проапгрейжено третьими лицами – вот вам и конкуренция.

Так называемый "Интернет вещей", который нам предстоит в ближайшее десятилетие, не должен использовать firmware, а то он станет дикой сетью. Кофеварка на Виндоуз – лучше, чем она же на безымянном коде от безвестного индуса. От Винды мы примерно знаем, чего ожидать, как защищать и где патчить.

white

Это какие-то неправильные логи

Логи, которые пишет подавляющее большинство программ, предназначены сисадминам, а не безопасникам. Они ориентированы на настройку взаимодействия, на поиск ошибок и неверной конфигурации, на оптимизацию ресурсов, на учёт потребления. А нам нужно – для расследования инцидентов, для выявления злоупотреблений, для поиска злоинсайдеров. Это ж совсем другой угол заточки.
       

Кроме того, нас обычно не устраивает, как логи хранятся. Сисадмину требуется, чтобы логи было удобно посмотреть, факторизовать, сравнить, агрегировать, посчитать статистику. А ещё – чтобы в случае падения программы она успела бы сказать что-нибудь на прощание, и эта запись не потерялась бы. У нас задачи перпендикулярные. Нам нужно по возможности изолировать логи от злоумышленника, затруднить их уничтожение и фальсификацию. А ещё – чтобы наши логи имели юридическую значимость, то есть оптимизировать их сбор и хранение под существующее процессуальное право.

Соответственно этому, по своей направленности логи должны поделиться на отладочные (традиционные) и криминалистические.

Примерно так, как уже поделились бэкапы. Обычное резервное копирование направлено на восстановление системы после сбоев. А криминалистическая копия диска делается для поиска следов при расследовании инцидента. Эти цели настолько различны, что обычный и криминалистический бэкапы даже не пересекаются – они делаются на разных устройствах, разными людьми, по разному расписанию.

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

white

Каждый сам несёт свой архив

Законами (а чаще – подзаконными актами) интернет-провайдеров обязывают хранить всякую информацию о пользователях. И чем дальше, тем более и более всякую. Вплоть до полной копии трафика.
       

Вспомним, что в офлайне предприятия тоже обязаны много чего хранить. Бухгалтерскую документацию, например, или документы материального учёта. Хранить – не для себя. А затем, чтобы проверяющие органы могли в любой момент проверить и найти нарушение. А кому ж хочется, чтоб у тебя нарушения находили за твой же счёт.

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

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

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

А вдруг информация о пользователе (его сообщениях, его трафике) понадобится для раскрытия преступления? Настоящего. Или даже пуще того – для предотвращения теракта? Хвать – а хранение-то фиктивное! Это ж какой будет минус в карму разработчикам! Спокойно. Я избавлю вас от химеры, именуемой моральными страданиями. Такого случая не будет. Никогда.

white

"Защита от честных людей"

Дорогие мои, сделайте пожалуйста так, чтобы я больше не слышал от вас этого глупого аргумента. Он вас совсем не красит, мои интеллектуальные читатели.

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

Все мы знаем теоретически, как разрезать колючую проволоку. Элементарно: щёлк-щёлк. А вот если практически идти в атаку на проволочные заграждения под огнём противника – будет совсем иной расклад. Наши ТСЗИ – они тоже применяются в комплексе.

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

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

white

Инциденты с паролями

В любом таком инциденте можно усмотреть долю вины обеих сторон:
Эти стороны между собой никогда не договорятся, кто из них больше виноват, кто должен исправиться. Требуется арбитр.

Но прежде чем говорить о решении споров, нужно создать закон, по которому будут решать. Каким критериям должна отвечать парольная политика? На какие ментальные усилия со стороны пользователя можно рассчитывать? Какие требования разумны, а какие – излишни? Среди RFC и стандартов ITU подобные документы вашему покорному слуге не попадались. При этом за такой "парольной конституцией" должен стоять авторитет известной и представительной организации.

К примеру, информационная система предусматривает обязательную смену пароля раз в три месяца. Пользователь их менял и записывал в особую книжечку (запомнить – нереально). Книжечка как-то раз закончилась. Он записал где попало и потерял. Обе стороны виноватят друг друга в этом инциденте. Принципы парольной политики должны нам дать ответ: была ли принятая политика адекватной; следовало ли рассчитывать на память пользователя или объём его блокнота? Отсюда и станет понятно, кто больше виноват.

А убытки от такого инцидента бывают шестизначные.