Куда послать проверяющих?

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

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

2. «гори оно все синим пламенем»

Да пусть они творят, что хотят. Мы берем их ноутбуки, настраиваем для работы с нашими информационными ресурсами, выпускаем в Интернет и всячески «содействуем». Разбирать этот сценарий нет смысла, так как это способ работы слабого, безвольного безопасника, не справляющегося со своими обязанностями.
3. «правильный»
Давайте порассуждаем. Не дать данные мы не можем, так как зачастую нам это выгодно, либо есть такое требование. Отдавать все не разумно, так как это может обнажить вещи, которые не предназначены для посторонних глаз. Идеально – контролировать, что передано проверяющим и, если не дай Бог, случится компроетация данных, иметь возможность доказать факт передачи. Пока все правильно.
Рассмотрим основные каналы передачи данных.

• локальная сеть – достаточно сложно контролировать, что было передано по ЛВС, слишком много протоколов (читай, возможностей);
• внешние носители – производители DLP хорошо отточили мониторинг этого канала;
• электронная почта – также достаточно легко мониторится;
• Интернет – собственно аналог локальной сети в части многообразия протоколов, но, поскольку, как правило, пользователям Интернет доступны всего несколько протоколов (например, HTTP и HTTPS), - на рынке доступны эффективные средства мониторинга и перлюстрации передаваемых через подконтрольный Интернет-шлюз данных.

Фотографирование экрана и ПЭМИНы не рассматриваю, ввиду крайности ситуации.
То есть нам нужно сделать так, чтобы аудитор мог получить данные, которые мы хотим ему отдать, обработать их и, возможно, увезти с собой. В то же время нам необходимо обеспечить контроль над тем, что он унес. Передача данных и контроль возможны на технических средствах, которые мы полностью контролируем, а это обычные ПК, которые раздаются пользователям. Отсюда описание сценария:
Аудиторам выдаются настроенные для работы во внутренней сети персональные компьютеры, с предустановленной DLP, с возможностью записи на внешние носители, без доступа в сеть Интернет и с возможностью отправлять электронную почту только внутри сети. В то же время, для работы с внешними ресурсами (корпоративная почта проверяющих, Интернет), их ноутбуки могут подключаются в чистый или почти чистый (если есть возможность контролировать (но не блокировать!) этот канал интернет, этим надо пользоваться) Интернет минуя внутреннюю сеть.
Для аудиторов оформляются обычные заявки на доступ к информационным ресурсам, которые инициируются курирующим подразделением.
При таком варианте, нам достаточно просто обеспечить работу аудиторов с внутренними ресурсами, даже самыми экзотическими и, в то же время, не дать им возможности унести данные, минуя наши системы мониторинга. Здорово получилось!

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

С++11 std::thread и передача переменных по ссылке

Издавна любители С были озабочены наличием единственного способа передачи переменных в функцию - по значению. Из этого следует, что внутри функции всегда копия переменной и как бы мы не меняли ее внутри функции, при выходе из нее значение переменной останется прежним.
Поэтому, если хочется менять переменную внутри функции, ее надо передавать по указателю. Работа с указателями для невнимательных людей типа меня может оказаться сущим адом, причем ошибку не всегда просто найти и понять.
Поэтому, разработчики языка С++ придумали механизм работы с "ссылками". Если в объявлении функции перед именем переменной стоит амперсанд "&", то С++ понимает, что данную переменную надо передавать в функцию по ссылке, - это означает, что изменения этой переменной, произведенные внутри функции, будут видны за пределами функции.
Отличная история! Теперь надо просто понимать какие переменные будут меняться в функции и ставить перед их именами амперсанд в объявлении функции. Далее работа с этими "ссылками" как с обычными переменными.

В спецификации С++11 появились потоки (класс std::thread). Ура! Не прошло и 30-и лет, как С++ предоставил API под многопоточное программирование. Синтаксис несложен: при создании потока указывается функция, которая, собственно, определяет, что поток делает.
Иногда хочется, чтобы поток мог менять переменные, поэтому хочется воспользоваться описанными выше достижениями С++ - "ссылками".
Можно попробовать оба варианта:
1. простая работа с ссылками, как-будто потоков и нет: в объявлении функции амперсанд перед именем переменной, далее - как обычно.
2. воспользоваться враппером std::ref(<имя переменной>) при объявлении функции вместо простого амперсанда, далее - как обычно - при вызове функции переменная передается обычным синтаксисом, как это было бы при стандартной передаче по значению.
Однако, оба варианта не работают в gcc 4.8, даже несмотря на то, что второй - в строгом соответствии со спецификацией С++11.
При компиляции с использованием gcc 4.8.2 высыпаются загадочные, но одинаковые в обоих случаях попытки использования ссылок, ошибки, привожу пример:
root@kali:~/src/JavaCG# make Brute.o
g++ -std=c++11 -pthread -c JavaCG/Brute.cpp -o Release/Brute.o
In file included from /usr/local/include/c++/4.8.2/thread:39:0,
                 from JavaCG/Brute.h:12,
                 from JavaCG/Brute.cpp:4:
/usr/local/include/c++/4.8.2/functional: In instantiation of ‘struct std::_Bind_simple’:
/usr/local/include/c++/4.8.2/thread:137:47:   required from ‘std::thread::thread(_Callable&&, _Args&& ...) [with _Callable = void (&)(int, _found*, SafeLong*, int**, int, Options&); _Args = {int&, _found*&, SafeLong*, int**&, int&, Options&}]’
JavaCG/Brute.cpp:192:83:   required from here
/usr/local/include/c++/4.8.2/functional:1697:61: error: no type named ‘type’ in ‘class std::result_of’
       typedef typename result_of<_callable rgs...="">::type result_type;
                                                             ^
/usr/local/include/c++/4.8.2/functional:1727:9: error: no type named ‘type’ in ‘class std::result_of’
         _M_invoke(_Index_tuple<_indices ...="">)
         ^
/usr/local/include/c++/4.8.2/functional: In instantiation of ‘struct std::_Bind_simple’:
/usr/local/include/c++/4.8.2/thread:137:47:   required from ‘std::thread::thread(_Callable&&, _Args&& ...) [with _Callable = void (&)(int, _found*, int**, int, Options&); _Args = {int&, _found*, int**&, int&, Options&}]’
JavaCG/Brute.cpp:215:70:   required from here
/usr/local/include/c++/4.8.2/functional:1697:61: error: no type named ‘type’ in ‘class std::result_of’
       typedef typename result_of<_callable rgs...="">::type result_type;
                                                             ^
/usr/local/include/c++/4.8.2/functional:1727:9: error: no type named ‘type’ in ‘class std::result_of’
         _M_invoke(_Index_tuple<_indices ...="">)
         ^
/usr/local/include/c++/4.8.2/functional: In instantiation of ‘struct std::_Bind_simple’:
/usr/local/include/c++/4.8.2/thread:137:47:   required from ‘std::thread::thread(_Callable&&, _Args&& ...) [with _Callable = void (&)(int, _found*, SafeLong*, _periods&, int**, int, Options&); _Args = {int&, _found*&, SafeLong*, _periods&, int**&, int&, Options&}]’
JavaCG/Brute.cpp:467:92:   required from here
/usr/local/include/c++/4.8.2/functional:1697:61: error: no type named ‘type’ in ‘class std::result_of’
       typedef typename result_of<_callable rgs...="">::type result_type;
                                                             ^
.........пропущено....................

make: *** [Brute.o] Error 1


Для случая Visual Studio 2013 вариант с амперсандом (&) не приводит к ошибке компиляции, но при этом переменная передается по значению, как и в случае без амперсанда. Вариант с враппером std::ref(<имя переменной>) работает корректно, как и предсказано спецификацией С++2011.

Писать в Visual Studio лично мне несравненно удобнее, чем в редакторе vi, поэтому, конечно же, я пишу изначально на VC++2013. Однако при переносе в Linux/gcc4.8.2, сломал весь мозг, что означают указанные выше ошибки.

И ни один выкинутый Гуглем пост мне не посоветовал просто: "Перестань пытаться использовать ссылки в функции для потока std::theread! Используй старые добрые указатели!"

В общем, независимо от того, баг это или фича, - не используйте ссылки при передачи параметров в функции потоков std::theread, используйте указатели!

Оценка материальных рисков

Проводить анализ рисков информационной безопасности необходимо хотя бы для того, чтобы понять сколько можно потратить на обеспечение безопасности, чтобы не заниматься глупостями когда возможный ущерб значительно ниже совокупной стоимости контролей безопасности.
Отлично, если удастся посчитать риски в деньгах - сразу получаем лимит суммы на безопасность.
Все риски адресовать не хочется, так как хочется распределять свои усилия более эффективно - будем рассматривать из множества рисков только материальные.
Так, к чему бы привязаться в плане материальности риска? Чтобы придать высокую корпоративную значимость процессу, давайте попробуем привязаться к готовому обороту Компании, - скажем, будем разбираться с риском, оценка в деньгах которого превышает 1% годового оборота.
Мы занимается, ИТ-безопасностью, по которой есть средне-мировая статистика бюджета ИБ от бюджета ИТ - 10%, что позволяет, имея абсолютно конкретный бюджет ИТ, прикинуть бюджет ИБ.
Ну и главное - поскольку мы задумываемся о таких серьезных вещах как количественная характеристика рисков ИБ, да и вообще говорим столько об этом - мы в крупной корпорации!
Ну-ка что у нас получится?
Годовой оборот - $5 млн.
Порог материальности риска - 1% * $5 млн = $50 к.
Бюджет ИТ - $200 к.
Бюджет ИБ - 10% * $200 к = $20 к
Вот ведь парадокс, - весь бюджет ИБ не превышает порог материальности риска!
Конечно же это здорово, что стоимость любых контролей ИБ [в любом случае] меньше материального риска, но важно и другое - независимо от эффективности инвестиций в ИБ (да вообще, независимо ни от чего!) все, что делает ИБ - не превышает допустимый уровень потерь для Бизнеса. Если при этом ИБ еще удается управлять материальными рисками, получается всегда исполнимый KPI  по эффективности: стоимость всей ИБ нематериальна, а предотвращаются материальные риски :-)

Ну что же делать, когда глупость подхода выше все-таки становится заметной?
На практике надо привязываться не к каким-то общекорпоративным показателям, которые не позволят проанализировать детали, а к показателям конкретного защищаемого бизнес-процесса. При этом стоимость бизнес-процесса можно рассматривать банальненько как стоимость его автоматизации со стороны ИТ (CapEx) и стоимость сопровождения этой автоматизации (OpEx) и уже от этого брать указанные выше 10% (соответственно на разработку и внедрение (CapEx) и последующую поддержку (OpEx)), в которые надо вписать всю безопасность. Материальность риска также надо оценивать применительно к бизнес-процессу, и в первом приближении это может быть просто стоимость простоя, рассчитанная из стоимости курящих бизнес-людей в совокупности со стоимостью усердно устраняющих инцидент подразделений ИТ и ИБ, пока сложные схемы оценки в деньгах конфиденциальности и целостности не пришли в голову. Может получиться, что беспокоиться об оценке в деньгах стоимости конфиденциальности и целостности уже и не надо, в случае, если стоимость возможного простоя (==стоимость доступности) превышает наши 10% на безопасность. Как правило, так оно и есть, чего уже достаточно для обоснования своей эффективности и адекватности, навешанной за 10% бюджета ИТ, безопасности.

Все запретить!

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


В нас снова вдалбливают стереотипы о том, что безопасность == запрещение/ограничение/блокировка.

Коллеги, времена изменились! Сейчас значительно эффективнее предоставлять сервис и мониторить коммуникации, возможно, даже скрывая сам факт мониторинга. Это позволит вам не просто найти того, кто что-то слил и посадить его на кол, а, вполне возможно, провести полноценное расследование, выявить более серьезные преступления, установить не очевидные связи, поймать "более крупную" рыбу. Не даром говорят, что кто владеет информацией - владеет миром. Так владейте информацией - собирайте ее, обрабатывайте ее. Блокируя информационные потоки, вы блокируете свою возможность собирать информацию, а информация - основа любого расследования.
Не надо, чтобы пользователи бежали с корпоративных устройств во всякие BYOD-ы, спасаясь от ограничений, пытаясь быть максимально эффективными - сделайте так, чтобы корпоративными сервисами было удобно пользоваться, чтобы пользователи выбирали корпоративную среду всегда, когда им надо поработать - это и будет лучшей защитой от утечки, а, вместе с тем, вы получите полный контроль над информацией и работой пользователя.

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

CISO Forum 2014

Вчера выступал на конференции. Презентацию выкладываю:

Infosecurity management in the Enterprise from Sergey Soldatov

С одной стороны, наверно, доклад получился интересным, потому что я старался разобрать как можно больше практических кейсов (действительно, у меня же был лабораторный практикум :-) ), с другой стороны, вследствие тех же постоянных уходов в сторону, доклад получился "рваным", к тому же, в отличие от Амстердама (где, напротив, осталось много свободного времени), здесь я фатально не уложился во время, а учитывая, что, как мне показалось, самое интересное было оставлено на конец, я даже немного огорчился. Однако, видя живой интерес аудитории к тому, что я рассказывал, воодушевился.

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

Ограничение бюджета как двигатель ИТ

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

Функциональные тендеры

Одной из "инноваций" высокой модели зрелости ИТ являются функциональные тендеры, заключающиеся в том, что в требованиях к автоматизации не указываются конкретные продукты, а указываются исключительно функциональные требования, что дает свободу выбора решения для потенциальных поставщиков, а для заказчика - возможность выбора решения, которое максимально удовлетворяет его требованиям и, вместе с тем, сопряжено с наименьшими затратами.
Считаю такой подход к решению проблем автоматизации концептуально неправильным, при условии, что мы начинаем не чистого листа, потому что он разрушает стандартизацию - нельзя судить о размере айсберга по его вершине, так нельзя выбирать и решение исключительно по функционалу. Есть разные взгляды на стандартизацию для информационной безопасности (некоторые говорят, что это плохо, аргументируя это тем, что одна уязвимость сразу будет доступна везде, так как все стандартно), но я сторонник того, что в крупной компании на первый план выходит возможность управлять процессами обеспечения ИБ, а в хаотичной инфраструктуре это сделать крайне проблематично (покрайней мере эффективность (effectiveness) такой работы будет низкая). ОК, зафиксировали, стандартизация для ИБ - это хорошо, и если в этом есть сомнения, этому можно посвятить отдельный пост.
Если мы стартуем не с чистого листа, то у нас уже есть сложившиеся практики управления процессами ИТ и ИБ, уже есть типовые решения, шаблоны, правила - читай, стандарты, - есть компетенции по тем или иным решениям, тем или иным вендорам, поэтому наши операционные косты невелики, что является хорошим показателем для ИТ/ИБ (поскольку и то и другое прежде всего косты и вся наша эффективная работа заключается в уменьшении этих расходов). Стандартизация - эффективнейший инструмент в борьбе с костами. Если мы играем функциональные тендеры, то мы намеренно идем на разрушение этих сложившихся практик - закупая всю жизнь недешевое железо от HP по функциональному тендеру мы можем получить серверы от "Depo-computers", а принтеры от Ricoh, а сетевое оборудование - Huawei вместо Cisco. При этом, мы, безусловно, снизим закупочную стоимость, но, почему-то, забывая о законе сохранения, не понимаем, что косты уйдя из закупки перекочевали в операционные расходы, собственно с чем ИТ/ИБ борятся всю свою жизнь: новые решения новых вендоров, будучи функционально эквивалентными, могут иметь отличные практики по их сопровождению, обслуживанию, обеспечению безопасности.... - все это потребует создания новых практик, обучения обслуживающего персонала, написания новых стандартов, модификации процессов сопровождения и обеспечения безопасности - это все стоит ресурсов и это нельзя выпускать из вида и всегда тщательно анализировать при принятии решения о необходимости проведения функционального тендера.
Всему написанному можно возразить, сказав, что все требования по вендорам и соответствия существующим практикам/стандартам можно вписать в требования. Но тут у меня разрыв шаблона, поскольку добавление таких требований убивает идею функционального тендера, ибо выбирается решение не функционально удовлетворяющее, а продукт конкретного вендора.
Я склонен думать, что все это типичный пример "побочных последствий" КПЭ (см. раздел Problems), когда закупщикам ставится цель снижения стоимости закупок и они успешно сливают эти расходы в Operations. Но надо же за деревьями и лес видеть!