PHDays 2012 ...послевкусие

Скажу сразу, это было круто ! В этом году я впервые оказался на PHDays и пробыл оба дня как на одном дыхании. Команда Positive Technologies сделала отличную работу и провела мероприятие на высоком уровне. Мне к сожалению пока не довелось побывать на зарубежных мероприятиях подобного уровня, но если ориентироваться на то, что пишут о них в Интернете, то PHDays ничем им не уступает (ну разве что определенной молодостью, т.к. это все же всего лишь вторая конференция). 

Теперь по конкретике. Почти все доклады на которых я побывал были очень интересными и, что самое главное, разноплановыми. Т.е. не было упора только в сторону низкоуровневого программирования или хакинга (как может показаться из названия). Каждый мог найти себе что-то по душе.   Помимо этого в течение этих двух дней проходила масса конкурсов, одним из которых, например, был поиск спрятанных точек WiFi-доступа.  Из-за этого среди массы участников периодически протискивались ребята с антеннами разной формы, те самые охотники на "лис". Меня даже один раз приняли за носителя "лисы" :)

Что мне довелось послушать:

1) Доклад по парольным менеджерам от Дмитрия Склярова и Андрея Беленко. Очень дельный доклад, ребята разобрали "по косточкам" с десяток парольных менеджеров для iOS и рассказали что в них не так.  Больше всего меня в таких обзорах конечно же радует описание программ, которые разработчиками подаются как средства надежной защиты паролей, а на деле их даже не шифруют.

2) Доклад Брюса Шнайера безусловно вызвал огромный интерес, хотя доклад был из серии нетехнической безопасности.  Брюс рассуждал на тему доверия как основы безопасности человеческого сообщества. Таких людей всегда интересно послушать, потому что их доклады заставляют в голове крутиться какие-то другие шестеренки и немного по-другому смотреть на свою работу.  Брюс конечно же немного попиарил свою последнюю книгу, которая как раз посвящена всему тому, о чем он рассказывал на докладе, но кто ж ему запретит. :). Речь, кстати, вот об этой книге если что.

3) Александр Гостев рассказывал про Flame, хотя в программе было обозначено, что разговор пойдет о Duqu, однако доклад от этого не стал менее интересным. Александр рассказал об их опыте в обнаружении и исследовании вирусов Stuxnet, Duqu и Flame, которые по его мнению являются примерами эволюции профессионального кибер-оружия.

4) Алексей Лукацкий в первый день рассказывал про непростые навороты нашего законодательства. Очень сгустил краски на мой взгляд, но народу в зале видимо было все равно, я даже не уверен, что половина из них вообще знает что такое ФСТЭК :).   Реально, там было колоссальное количество молодежи, людей, которые как я вскользь услышал, называют таких как я "пиджаками" :). Вот та молодая шпана, что сотрет нас с лица земли, как пел БГ.

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

Еще один интересный доклад, который я посетил во второй день, был доклад Джерри Гэмблина про Lulzsec. Джерри рассказал об участниках группировок Lulzsec и Anonymous, об их операциях и методах, которыми они пользовались. Кстати, во время доклада 5 человек из сидевших в зале одели маски Anonymous и вышли :)  такой вот флешмоб получился.   Еще порадовал вопрос одного из журналистов, заданный Джерри, "простите, а вы не Anonymous ?".

Да, параллельно со всем этим действом проходили хакерские соревнования CTF. Я не остался на награждение в конце второго дня, но как я понял, в итоге победила команда Leetmore. Молодцы ребята ! 

Подводя итог могу сказать, что я очень рад, что у нас в России появилось такое мероприятие. И я желаю всем организаторам долгих лет жизни :) т.к. сделать такое - это очень непростая и я уверен довольно затратная по деньгам задача. Надеюсь, ребята, что вы не сбавите оборотов.

Зовите меня на PHDays 2013, я обязательно приду !   И под конец немного фоток:

 

Всем спасибо...

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

Прикольный ролик от Group-IB

Осторожно, реклама !

Ну держитесь коррупционэры !

Ликбез по AET от Stonesoft

На прошлой неделе ваш покорный слуга в числе группы из нескольких человек был приглашен посетить штаб-квартиру компании StoneSoft в Финляндии для прохождения тренинга Hack the Lab и участия в дискуссии на тему AET (advanced evasion techniques). Так как мои коллеги уже успели о многом рассказать, то отсылаю вас к их блогам:

Евгений Царев - ссылка

Алексей Комаров - (aka Тарас Злонов) ссылка

Игорь Хайров - ссылка

Я же в своем посте хотел бы немного коснуться именно вопроса тех самых продвинутых техник обхода (AET). Суть их заключается в том, что используся различные особенности реализации стека протоколов TCP/IP можно обходить имеющиеся на рынке IDS/IPS/FW решения и успешно реализовывать атаку на защищаемый хост. 

В настоящий момент уже известны сотни таких техник, а если учесть, что их можно комбинировать, то количество возможных вариантов устремляется к заоблачным значениям. Так что на перебор и тестирование всех возможных вариантов может не хватить и нескольких лет. Однако надо понимать, что для успешного применения AET необходимо стечение различных факторов, точнее характеристик и особенностей реализации (как я уже сказал) стека TCP/IP на защищаемом узле и средствах сетевой безопасности.

Довольно неплохое описание примеров техник обхода (что они собой представляют и за счет чего реализуются) есть тут - ссылка.

Для тех кто больше любит смотреть, чем читать предназначено вот это видео (на английском):

Компания Stonesoft в том числе сделала отдельный сайт на тему AET -   http://aet.stonesoft.com/. На этом сайте, кстати, можно отправить заявку на провеку своих систем на устойчивость к атакам с применением AET.

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

Также в беседе отмечалась и довольно вялая реакция разработчиков на угрозу, которая исходит от AET.  Собственно подтверждение тому вот эта статья:

Security vendors slow to respond to new evasion techniques (via GCN)

By William Jackson Aug 04, 2011 LAS VEGAS — Ten months after Stonesoft Corp. announced the first batch of sophisticated techniques to help malware avoid standard detection methods, few security vendors are responding to what are called advanced evasion techniques. Mark Boltz, senior solutions architect…

Нормативка от ЦБ под закон о НПС (чтиво на выходные)

На сайте Центрального Банка РФ появилась парочка документов, которые как мне думаются будут интересны многим. Читаем, изучаем, комментриуем, коллеги:

"Положение. О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств" - ссылка.

"Указание. Об отчетности по обеспечению защиты информации при осуществлении переводов денежных средств операторов платежных систем, операторов услуг платежной инфраструктуры, операторов по переводу денежных средств" - ссылка.

А не написать ли нам министру ?

Коллеги, вчера через свой твиттер ( http://twitter.com/#!/nnikiforov)  новый глава Минкомсвязи Николай Анатольевич Никифоров объявил сбор предложений относительно тех проблем, на которые Министерству стоить обратить внимание. В связи с этим у меня появилась идея собрать не только проблемы, но и предложения относительно того, что надо сделать по профилю информационной безопасности. Так что пишите мне коллеги, собираю ваши предложения и замечания до конца этой недели, далее систематизирую и опубликую их в моем блоге.

Писать можно в комментариях к этому посту, на мою личную почту (кто знает) или через эту форму

У Минкомсвязи новый глава !

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

Сегодня хочу высказаться на злобу дня что называется. Как вы наверное уже знаете, Минкомсвязи сменило руководителя. Министром назначен Николай Никифоров (на фотографии). 

Коротко об этом человеке:

• Николай Анатольевич Никифоров родился 24 июня 1982 года в городе Казани (Татарстан).
• В 2006-2010 годах Николай Никифоров был генеральным директором Центра информационных технологий Республики Татарстан. На этой должности он занимался формированием электронного правительства республики.
• Николай Никифоров награжден медалями "За укрепление государственной системы защиты информации", "За содружество во имя спасения", "В память 1000-летия Казани", "За укрепление боевого содружества".

Министр молод, поэтому предположу, что ему не будут чужды идеи модернизации. Как известно Роскомнадзор находится в ведении Министерства связи и массовых коммуникаций Российской Федерации, а значит и вопрос исполнения нашего любимого 152-ФЗ тоже. 

Кстати, у министра есть твиттер - http://twitter.com/#!/nnikiforov

Может быть не все потеряно, коллеги ?  Как думаете, есть шанс найти взаимопонимание ?

Проверка на "вшивость" или Новые постановления правительства

Вопреки возможным ожиданиям я не буду писать ничего о новых Проектах постановлений правительства, касающихся вопросов защиты персональных данных (в соответствии с последними изменениями 152-ФЗ).  По крайней мере пока. Скажу лишь, что я считаю, что они мягко говоря не доработаны. 

Ряд коллег, уже высказали свои впечатления. Привожу ссылки:

Алексей Волков - http://anvolkov.blogspot.com/2012/04/blog-post_27.html

Артем Аветян - http://avetjan.livejournal.com/23148.html

Ригель - http://xpomob.blogspot.com/2012/04/781.html

Евгений Шауро - http://shaurojen.blogspot.com/2012/04/blog-post_28.html

Сергей Борисов - http://sborisov.blogspot.com/2012/04/blog-post_27.html

Я же хочу сказать следующее. Есть такая фраза "каждый народ имеет то правительство, которое он заслуживает".  Это из письма (от 27 августа 1811 г.) посланника Сардинского королевства при русском дворе графа Жозефа де Местра (1753—-1821). В этом письме граф писал своему правительству о новых законах, установленных императором Александром I.

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

ФСБ вроде как ждет наших предложений до 2 мая (сроки конечно умиляют). Потом еще будет проверка в МЭР и Минюсте. В МЭР свои замечания можно будет слать абсолютно свободно. В проверке Минюста смогут участвовать только аккредитованные эксперты. Я уже писал об этом заранее. Кстати, кто-то из вас кроме меня подал документы на аккредитацию в качестве эксперта на коррупицогенность ? (это к вопросу о нашей активности как сообщества). 

В общем, эти постановления правительства - это в первую очередь проверка на "вшивость" нашего сообщества. Так чего мы стоим и чего заслуживаем, коллеги ?

Размышления об оценке рисков

В сегодняшнем посте я хотел бы порассуждать на тему такого спорного вопроса как "оценка рисков ИБ".

С одной стороны необходимость проведения такой оценки предписывается практически всеми стандартами/международными практиками.  Возьмем самые основные:

ISO 27001: 

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

Организация должна делать следующее:

c) Определить подход организации к оценке рисков.

d) Идентифицировать риски.

e) Проанализировать и оценить риски.

f) Идентифицировать и оценить возможности по обработке рисков.

PCI DSS:

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

СТО БР ИББС-1.0:

8.4.1. В организации БС РФ должна быть принята/корректироваться методика оценки рисков нарушения ИБ / подход к оценке рисков нарушения ИБ.
8.4.2. В организации БС РФ должны быть определены критерии принятия рисков нарушения ИБ и уровень допустимого риска нарушения ИБ.

8.4.4. Оценка рисков нарушения ИБ проводится для свойств ИБ всех информационных активов (типов информационных активов) области действия СОИБ.

Cobit 5.0:

Процесс APO12 Manage Risk
1. Collect data.
2. Analyse risk.
3. Maintain a risk profile.
4. Articulate risk.
5. Define a risk management action portfolio.
6. Respond to risk.

и многие, многие другие..... 

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

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

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

Возьмем пример. Вы выходите на должность руководителя отдела ИБ, какие ваши дальнейшие действия ? Варианта два: либо вы доделываете то, что уже делал ваш предшественник, но тогда это просто означает, что вы исполняете решения, принятые до вас (принятые, возможно, на основе мнения предшественника), либо вы начинаете наводить порядок, обнаруживаете наиболее проблемные места и пытаетесь их закрыть.  Это же классическая оценка рисков:

1. Вы определили основные активы (то за что, вам могут дать по голове в случае чего) 

2. Вы обнаружили проблемы (они же уязвимости)

3. Вы определили к чему эти проблемы могут привести (определили угрозы)

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

Сразу оговорюсь, что здесь я не учитываю необходимость проведения обязательных мероприятий. Соответствие требованиям практически никак с риск-менеджментом не пересекается. Требования могут быть либо обязательными, либо производными от оценки рисков. По другому быть не может (хотя наши регуляторы в старых НПА, вышедших под 152-ФЗ предложили именно такую нежизнеспособную схему, существовали и классы (обязательные требования) и модель угроз (оценка рисков), посмотрим что будет в новых). 

И вот что еще важно отметить. Есть принципиальное отличие в подходах к риск-менеджменту в существующих стандартах по ИБ.

Если мы возьмем стандарт ISO 27001, то увидим, что он содержит в себе минимальный набор требований к самой системе менеджмента ИБ, а выбор конкретных мер по защите как раз и производится на основании оценки рисков. 

А если мы возьмем стандарт PCI DSS (который, кстати, многие хвалят) или СТО БР ИББС-1.0, то там оценка рисков - это всего лишь один из элементов безопасности наряду с массой других, определенных в стандарте.  Именно это и приводит к тому, что многие специалисты по ИБ задают вопрос, а зачем вообще проводить оценку рисков.  Мы же уже реализовали огромное количество требований, написанных в стандарте, т.е. мы практически все риски перекрыли, зачем теперь еще и оценку проводить ?  Ответ прост - стандарт определяет набор базовых требований и поэтому оценку рисков ИБ следует проводить для того, чтобы определить необходимость реализации дополнительных защитных мер для конкретных активов, защита которых не обеспечивается выполнением базовых требований, определенных в стандарте.

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

Законотворческий процесс в действии

Коллеги, еще 13 февраля я писал о появлении проекта постановления правительства "Об утверждении Положения о защите информации в национальной платежной системе".  Проект был опубликован на сайте ФСТЭК, а также передан на оценку регулирующего воздействия в МЭР  и оценку коррупционгенности в Минюст. Об этих оценках я уже писал ранее.

Кстати, интересно было почитать заключение МЭР на этот законопроект. Оно опубликовано здесь. Приведу ключевую для меня выдержку:

2. В соответствии с абзацем 2 пункта 14 проекта Положения предусматривается, что «контроль (оценка) проводятся субъектом платежной системы самостоятельно и (или) с привлечением на договорной основе организаций, имеющих лицензию на деятельность по технической защите конфиденциальной информации». Исходя из указанной формулировки проекта Положения, полагаем, могут возникнуть необоснованные основания в дублировании контроля (оценки), в случае его проведения субъектом платежной системы самостоятельно и с привлечением на договорной основе организаций, имеющих лицензию на деятельность по технической защите конфиденциальной информации. В связи с этим считаем необходимым уточнить редакцию абзаца 2 пункта 14 проекта Положения.

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

Кроме того, полагаем, что положения абзацев 4 и 5 пункта 14 проекта Положения не позволяют однозначно определить периодичность проведения контроля (оценки). Так, с одной стороны в проекте Положения предусматривается установить периодичность осуществления контроля (оценки) требований к защите информации в платежной системе «не реже раза в два года» (абзац 4 пункта 14 проекта Положения). С другой стороны, предполагается установить, что «контроль (оценка) выполнения требований к защите информации в платежной системе может осуществляться в ходе аудита субъекта платежной системы, проводимого в соответствии с законодательством Российской Федерации об аудиторской деятельности» (абзац 5 пункта 14 проекта Положения). Отмечаем, что в соответствии с пунктом 2 статьи 5 Федерального закона от 30 декабря 2008 г. № 307-ФЗ «Об аудиторской деятельности», в частности, обязательный аудит проводится ежегодно. Одновременно, в абзаце 5 пункта 14 проекта Положения представляются неясными случаи, в которых «обеспечение защиты информации включено в перечень сопутствующих аудиту услуг, устанавливаемому федеральными стандартами аудиторской деятельности и (или) стандартами аудиторской деятельности саморегулируемых организаций аудиторов».

Таким образом, полагаем, что пункт 14 проекта Положения требует существенной доработки.

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

Кстати, на днях проект этого документа появился на сайте АРБ (ссылка). Текст оригинальный и замечания МЭР не учитывает. Интересно, это АРБ запаздывает с публикацией документов на пару месяцев или все же это сигнал, что документ скоро примут в его изначальной редакции ?

В любом случае этот документ показывает государственную машину в действии. Проект появился в середине февраля, сейчас уже конец апреля, он все еще не принят, не понятно устранены ли замечания и будут ли вообще устраняться. Так что Постановлений правительства под новый 152-ФЗ нам еще придется подождать. Минимум месяца 2 до официального подписания это точно, а более вероятно, что вообще только к осени.

По итогам форума директоров ИБ

Сегодня завершился второй, заключительный день Форума директоров ИБ. Несколько наиболее ярких моментов, которые я лично для себя выделил:

1) Представитель ФСБ рассказал, что проект нового Постановления Правительства под 152-ФЗ про уровни защищенности должен быть опубликован в ближайшее время. Если я правильно понял, то переход к уровню защищенности будет через какую-то комбинацию класса системы (по схеме классификации типовых систем) и модели нарушителя. 

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

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

3) Еще я отметил, что в риторике представителей ФСТЭК и ФСБ все чаще звучит то, что их назначили ответственными за контроль государственных информационных систем, а то, как будет организован контроль коммерческих организаций их не особо интересует. Это не их задача. 

4) И в заключение на основании доклада Алексея Волкова я отмечаю, что действительно все разговоры в кулуарах конференций не значат ничего и точку в большинстве вопросов может поставить только СУД.  Готовьте свои аргументы, коллеги !

Проблематика защиты мобильных устройств (часть 3) - утечка данных

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

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

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

Каким образом можно указанные риски минимизировать ?

1) Применение криптографии

Здесь есть определенные трудности. Во-первых отечественной криптографии для шифрования устройств нет, да и вряд ли она появится в ближайшее время (я говорю именно про шифрование устройств, а не про VPN). Все шифрование может быть организовано исключительно средствами самого устройства и здесь в первую очередь возникает вопрос как рулить этим механизмом централизованно. Для этих целей потребуется развернуть MDM-систему (mobile device management). Об этих продуктах я подробнее будут писать в последующих постах на тему мобильной безопасности.

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

2) Усиленный контроль доступа

Т.е. использование на устройствах пароля доступа (passcode). И тут конечно же важно не просто его наличие, но и требования к сложности пароля. Чтобы не получилось вот это:

Опять же тут встает вопрос централизованного управления политиками безопасности, который в настоящий момент также решается с помощью MDM систем.

Еще один момент: пользователь может использовать не код доступа, а специальную программу, которая заменяет код на рисунок, который должен нарисовать пользователь, чтобы разблокировать устройство. Здесь MDM системы бессильны, непонятно каким образом определять необходимую сложность подобного рода механизмов доступа.

3) Использование DLP-систем для мобильных устройств 

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

4) Исключение хранения информации на мобильном устройстве

Конечно же это не всегда возможно в силу того, что у нас пока еще не везде можно обеспечить уверенный прием 3G/WiMax сигнала, который позволит работать с удаленным сервисом без хранения информации на устройстве.

Однако в тех случаях, когда обстоятельства это допускают, исключить хранение можно несколькими способами:

1) Использование специальных клиентов для доступа к прикладным системам, которые исключают хранение информации на устройстве.

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

2) Использование веб-приложений, позволяющих просматривать информацию в браузере без возможности сохранения документа.

Способ не самый надежный, т.к. не существует возможности заблокировать функции самого браузера (например, копирование текста).

3) Терминальный доступ с мобильного устройства к корпоративному серверу, на котором хранится необходимая информация/приложения

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

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

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

Межбанковская конференция "Вопросы обеспечения безопасности НПС"

Для информации, коллеги, 7 июня 2012 года состоится Межбанковская конференция "Вопросы обеспечения безопасности Национальной платежной системы и дистанционного банковского обслуживания». Место проведения: Москва, Конгресс-центр МТУСИ. 

Обсуждаемые вопросы:

• Регулятивная функция Банка России в свете выполнения закона "О национальной платежной системе"
• О документах Банка России по информационной безопасности в рамках закона "О национальной платежной системе"
• Обеспечение бесперебойности функционирования платежной системы: роль и место вопросов информационной безопасности
• Механизмы саморегулирования субъектов предпринимательской и профессиональной деятельности в кредитно-финансовых и других организациях – участниках национальной платежной системы Российской Федерации
• Нормативные и технические вопросы обеспечения безопасности систем ДБО
• Практический опыт совершенствования систем ДБО
• Взаимодействие банковского сообщества по решению проблем обеспечения безопасности систем ДБО

Подробнее -  http://www.ib-bank.ru/dbo/

Open source в инфобезопасности

Помню на волне кризиса, который начался в 2008 году, шло немало разговоров (в т.ч. на уровне государства) о возможном переходе на СПО (свободно распространяемое программное обеспечение, open source).  Я даже в свое время размещал список open source решений, которые могут быть полезны для безопасника.  Сейчас эти разговоры поутихли, да и активное развитие облачных и мобильных технологий серьезно повлияло на рынок ПО.  В связи с этим у меня возник вопрос к читателям этого блога. А вы используете open source решения для обеспечения информационной безопасности ? Если да, то какие ?  Напишите в комментариях.