Тенденции законодательства по ИБ. Презентация с семинара RISC

Моя презентация с мастер-класса для RISC по тенденциям российского законодательства в области ИБ. Запись будет выложена на сайте RISC.

Планируемые изменения законодательства по ИБ в России from Alexey Lukatsky

IBM покупает Lighthouse Security Group и CrossIdeas

Вчера, 11 августа компания IBM объявила о приобретении провайдера услуг IAM облачной безопасности - Lighthouse Security Group. Детали сделки не разглашаются.

Неделей ранее, 31-го июля, IBM приобрела другую компанию на рынке ИБ - CrossIdeas, которая является разработчиком ПО для обеспечения доступа пользователей к корпоративным и облачным приложениям. Детали сделки также не разглашаются. 

Gemalto покупает SafeNet

8-го августа голландская Gemalto объявила о планах приобрести американскую SafeNet за 890 миллионов долларов.

Страх как тормоз развития ИБ

Намедни встречался я с одним чиновником, в функции которого входило принятие решения по одному нормативному акту. Решение он принял отрицательное, попутно говоря о государственности, ответственности перед детьми, новом курсе России, и использовал иные аналогичные сентенции. А уже на пути от него я подумал, что причина его отказа кроется не в нежелании что-то делать, а в страхе! Да-да, в страхе неизвестного.

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

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

Тут впору вспомнить эффект Даннинга-Крюгера, который тоже имеет место у чиновников, но разговор не о нем. Непонимание объекта регулирование приводит к тому, что предсказать, чем закончится “да” проекту нормативного акта заранее нельзя. Может стать как хорошо (чиновнику), так и плохо. Вдруг не только по головке не погладят, но и выпорят еще за отсутствие следования линии партии. А раз в результате положительного решения чиновника сквозит полная неопределенность, то ему проще сказать “нет”. Что чиновник как правило и делает.

Геронтолог Обри ди Грей в статье “Чувство меры в страхе перед неизвестным” так высказался об этом: “Один аспект этой проблемы особенно важен с точки зрения желания общественности избежать некомфортных для себя ситуаций — это неприятие риска. Когда неопределенность проявляется в таких областях, как этика (если речь идет о ядерном трансфере) или экономическая политика (как в вопросе вакцинации против гриппа), соответствующее планирование помогло бы избежать потенциальных проблем. Но когда дело касается отношения общества к риску, все намного сложнее… Да, решение приняли органы власти, но в полном согласии с общественным мнением.”

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

Обри ди Грей продолжает: “Реакция на соотношение риска и пользы в области передовых технологий — пример страха перед неизвестным. Это иррациональная склонность придавать большее значение риску, закрывая глаза на преимущества”. Вспомните, сколько раз ФСБ запрещала применение новых технологий? А ФСТЭК (по крайней мере до 2013 года)? А ЦБ, который только до сих пор не имеет требований по безопасности платежных карт или облачных АБС или банкоматов (а ведь они применяются не первый год)? А все просто - у ЦБ нет ни того, ни другого, ни третьего. Они не знают (не знали) как подступиться к регулированию этой темы и поэтому бездействовали, откладывая ее “на потом”.

“Страх перед неизвестным в принципе вовсе не иррационален, если под страхом понимать разумную осторожность, но эту грань легко переступить. Если бы общественность можно было научить оценивать риск, с которым связано развитие технологий будущего, и разъяснить необходимость мириться с кратковременным риском в интересах очень существенных ожидаемых преимуществ, это ощутимо ускорило бы прогресс во всех областях”. Так Обри ди Грей написал про постоянные препоны науке со стороны общественности. Но тоже самое можно сказать и про другие сферы нашей жизни, которые направлены на улучшение жизни. Например, на внедрение тех или иных информационных технологий или технологий ИБ. А “общественность” можно заменить на “чиновника”. И тогда мы получим причины, по которым большинству последних инициатив либо говорят нет, либо почему новым технологиям не дают хода. Просто перспективы их не так очевидны, а разумная осторожность часто переходит в необдуманный запрет или полное игнорирование (что еще хуже, т.к. представляет собой неопределенность).

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

“Если вы не можете увидеть решение прямо “сейчас”, это еще не значит, что решения как такового не существует. Вы лишь должны двигаться дальше, чтобы увидеть это решение. По крайней мере, вам придется для собрать некоторую дополнительную информацию о том, как вы можете добраться до нужного ”решения”.”

“Доверяй, но проверяй”? Или доверие пора выбросить в унитаз?

Большинство из нас училось информационной безопасности на концепции доверия. Есть сеть внутренняя, а есть внешняя. Есть пользователи доверенные, а есть не очень. Есть зона контролируемая, а есть бесконтрольная. Есть доверительные отношения между доменами, а есть обычные. Есть соединения доверенные, а есть небезопасные. Есть доверенный интерфейс у МСЭ (как правило, внутренний), а есть недоверенный (как правило, внешний). У некоторых средств сетевой безопасности интерфейсы даже так и назывались trusted и untrusted. Знакомая концепция, не правда ли?

И вот пришел… Нет, не Дед Мороз. И не тот самый пушной зверек. Обычный американский парень - Эдвард Сноуден. А до него был другой Эдвард - Бредли Эдвард Меннинг, который совсем недавно стал Челси Элизабет Меннинг (кстати, тем, кто задумал украсть корпоративные секреты своего работодателя, стоит задуматься о том, к чему приводят действия против закона :-) Они ярко продемонстрировали, что даже в святая святых органов обороны и нацбезопасности поговорка “чужие здесь не ходят” не работает. Скорее наоборот. Не совсем понятно, откуда вообще взялась идея, что в безопасности можно кому-то или чему-то доверять? Это ведь корень всех провалов. Стоит скомпрометировать доверенного пользователя, узел, приложение… и безопасности приходит конец; надо все перестраивать с нуля. И так каждый раз, когда проявляется новый Сноуден, Меннинг, Филби, Рейли, Розенберг, Фишер, Коэн, Пеньковский. Я не берусь сейчас оценивать действия данных лиц с моральной или какой-либо иной точки зрения. Разведчики они или предатели… Не так уж и важно. Я хотел бы оценить эти события только с точки зрения информационной безопасности. Выше я перечислил несколько имен, которые на протяжении последних ста лет показывали порочность практики “доверительных отношений” в ИБ. Не пора ли от нее отказываться? Об этом не первый год говорят как в англоязычной среде, продвигая концепцию Zero Trust, так и у нас, ругая концепцию “контролируемой зоны” от ФСТЭК. Я тоже не обошел внимание эту тему, выступив в 2012-м году на PHDays с соответствующей презентацией.

Вчера я сдал статью в очередной номер "!БДИ", в которой писал о том, почему управление ИБ дает сбой. В качестве причин назвал я и концепцию доверия, а также неготовность к неожиданностям, которая вытекает из этого доверия. Ну какие неожиданности могут быть от администратора СУБД или даже руководителя службы ИБ? А от вендора, с которым мы работаем уже не первый год? А от контрагентов, с которыми у нас заключены договора на поддержку? Так думаем мы и ошибаемся.

Сегодня наступило время, когда надо в корне менять подходы к обеспечению ИБ на предприятии (что на коммерческом, что на государственном). Сегодня не должно быть ничего доверенного. Вокруг одни враги! Даже внутри сети. И речь идет не столько о рядовых пользователях, которые по ошибке совершают несанкционированные действия, сколько о реальных злоумышленниках, которые могут сидеть в вашей сети месяцами и тащить из нее все, что плохо лежит. А в локальных сетях обычно лежит плохо все. Ну непринято у нас (и у них тоже) защищать внутреннюю сеть. Максимум - это поставить антивирусы на внутренние ПК. Ну и огородить локальную сеть стеной из межсетевых экранов, систем предотвращения вторжений, систем контентной фильтрации и других не менее ценных, но ограниченных только периметром средств защиты. Все, что пойдет через них, будет просвечиваться тремя-пятью лупами; зато внутри у нас раздолье. Пользователи ходят куда хотят и на уровне сети их никто не ограничивает. На уровне серверов приложений им, может быть, и создаются препятствия, но внутри трафик никто не шифрует и поэтому, даже не имея доступа к серверам с ценной информацией, ее можно перехватывать обычным сниффером. Принцип минимума привилегий, часто реализуемый на уровне ОС или СУБД, почти никогда не внедряется на уровне сети. Отсюда постоянные утечки и бесполезные попытки с ними бороться. Бороться ведь надо не с утечкой, а с ее причиной. Ограничьте доступ внутри и снимете львиную долю проблем. Например, у нас в Cisco именно такая концепция защиты ценной информации (моя презентация с DLP Russia) и она дает свои плоды.

Кстати, об уровне сети. Какие самые популярные средства сетевой безопасности у нас обычно ставятся? МСЭ и IPS. И те, и другие на периметре сети. Иногда еще и на отдельных участках внутренней сети, но современная коммутируемая сеть (да еще и с виртуализацией или SDN) ставит крест на попытках найти отдельные точки контроля, в которые стекается весь трафик. Но даже если представить, что мы смогли пропустить весь трафик через несколько точек контроля и они не превратились в узкие бутылочные горлышки, то что дальше? А если на доверенном узле, чей трафик разрешен на МСЭ, незаметно работает фрагмент APT или бот? Он будет работать от имени доверенного пользователя или узла, которому разрешено многое. Сетевой трафик не может быть доверенным в принципе. Именно поэтому появляются такие технологии как 802.1x, NAC/ISE, NBAD/CTD, разрабатываемые из расчета, что одной аутентификации пользователя недостаточно и нужно более пристально всматриваться в сетевой трафик, идущий между устройствами (особенно если пользователь за устройством вообще не присутствует и никакой аутентификации не проходит).

“Ни фига!”, - возразите мне вы. Я могу контролировать все, что есть в моей сети и на подступах к ней! У меня множество средств защиты (Forrester насчитывает 17 основных типов средств сетевой безопасности, используемых сегодня по всему миру), они все именитые, на них потрачено много денег и они не могут меня обманывать! Я им доверяю! Вот! Почему вы им доверяете? У вас есть основания? Вы лично проверили эффективность всех средств защиты или просто верите производителю на слово? Как показывает статистика такое доверие дорого обходится. В известных случаях вредоносный код “сидел” внутри по несколько лет и успевал за это время стянуть несколько терабайт данных. И все это при наличии разнородных средств защиты. Значит ли это, что все они плохи? Нет! А можно где-то найти решение, реализующиее технологию “нулевого доверия”? Тоже нет! Их не существует в природе!

Потому что концепция Zero Trust не означает новой серебряной пули или очередной революции на рынке средств ИБ. Это просто смена парадигмы, которая может быть реализована за счет существующих решений и технологий. Надо поменять свое сознание и строить систему ИБ на предприятии исходя из того, что никому и ничего доверять нельзя. Нельзя “доверять, но проверять” - можно только “проверять и никогда не доверять”! Проверять ПО перед установкой и после нее. Проверять все сетевые соединения снаружи и внутри. Проверять все попытки доступа любых пользователей независимо от их роли. Проверять все устройства, подключаемые к сети. Проверять трафик на всех TCP-портах, а не только на тех, которые, как мы считаем, доступны в сети. Проверять прикладной трафик, включая и возможную инкапсуляцию в него чего-то вредоносного или просто нарушающего политику ИБ.
Эксперты выделяют три составляющих концепции “нулевого доверия”, с которыми я склонен согласиться:

1. Контролируйте и защищайте все. Неважно, кто, откуда, когда, как и зачем осуществляет подключение. Важно проверять все - тогда уровень безопасности сети повысится, а число неприятных сюрпризов существенно уменьшится. Для специалистов по ИБ не должно быть разницы между защитой внутренних активов от внутренних нарушителей и защитой внешних активов от внешних злоумышленников. Для этого достаточно будет пересмотреть правила и настройки существующих средств защиты.
2. Минимум привилегий и контроль доступа на всех уровнях. Этот принцип должен быть реализован не только на уровне ОС, приложений или периметра. Важно реализовать его и во внутренней сети с помошью встроенных в сетевое оборудование или наложенных средств защиты (первые предпочтительнее). Для этого необходимо использовать средства контроля сетевого доступа (NAC) и производные от него (например, TrustSec).
3. Инспекция и регистрация сетевого трафика. Нарушитель сегодня в состоянии выдать себя за легального субъекта доступа - пользователя, узел, приложение, процесс. В конце концов злоумышленник может и вовсе оставаться невидимым для средств защиты навесных или установленных не в том месте сети (такое часто бывает, когда в сети появляются несанкционированные 3G/4G-модемы или беспроводные точки доступа). Поэтому необходимо фиксировать весь сетевой трафик и проводить его инспекцию на предмет нарушений политики безопасности (ее, кстати, тоже надо пересмотреть в контексте “нулевого доверия”). Для этого необходимо использовать решения класса NBAD (Network-based Anomaly Detection) и SIEM.

Разумеется, отказ от идеи “доверяй, но проверяй” в пользу “проверяй, никогда не доверяй” - это не сиюминутная задача и не одноразовый проект. Это, в первую очередь, смена классической парадигмы, которой до сих пор учат выпускников ВУЗов по ИБ. Главное, поменять сознание. А уж затем планомерно и последовательно внедрять эту идею на существующих средствах защиты, возможно, приобретая и что-то новое, чего раньше не было (обычно это средства или встроенные механизмы защиты внутренней сети). При этом не всегда это требует серьезных финансовых затрат - очень часто все необходимые компоненты уже присутствуют и их просто надо правильно настроить.

Дело осталось за малым - начать!..

ИБ-требования к разным этапам жизненного цикла АБС вступают в силу с 1-го сентября

На прошлой неделе Банк России выложил у себя на сайте рекомендации в области стандартизации Банка России «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем» (РС БР ИББС-2.6-2014), которая вводится в действие с 1-го сентября 2014-го года.

Идея у данного документа достаточно простая - немалое количество проблем с безопасностью в кредитных организациях происходит по причине не очень высокой защищенности АБС, используемых в банках. Но если выстраивать процессы ИБ вокруг АБС банки умеют, то что делать с приобретаемой и местами дырявой системой было непонятно. Влиять на разработчиков Банк России напрямую не может; к мнению заказчиков многие разработчики тоже прислушиваются редко. И вот был предложен способ, который может повлиять на ситуацию в лучшую сторону. ЦБ дает указание банкам, а те транслируют его исполнителям - разработчикам АБС, которые выполняют не "хотелки" заказчика, а распоряжение отраслевого регулятора. И вот именно такое распоряжение и представляет собой РС 2.6.

Документ разбит, по крупному, на 3 части, последние 2 из которых вынесены в приложения:

• Требования по организации работ на разных стадиях жизненного цикла АБС.
• Список из 122 типовых проблем АБС с точки зрения безопасности.
• Рекомендации по контролю исходного кода АБС и оценке ее защищенности, включая проведение пентестов.

Выделяется 7 этапов, для каждой из которых прописаны свои требования по ИБ.

1. Стадия разработки технического задания
2. Стадия проектирования АБС
3. Стадия создания и тестирования АБС
4. Стадия приемки и ввода в действие
5. Стадия эксплуатации 
6. Сопровождение и модернизация АБС
7. Стадия снятия с эксплуатации.

Многие мои комментарии и замечания были устранены еще на этапе обсуждения этого документа в ТК122, за исключением двух. Во-первых, документ ну вот совсем никак не рассматривает такое нередкое у нас явление, как иностранные АБС. И особенно АБС (или их компоненты), которые установлены в штаб-квартирах иностранных банках, которые используются и их российскими дочками. А второе мое замечание касалось облачных АБС. Яркий пример - Factura.ru. Вот как к такой АБС применить требования РС 2.6? Она вроде и не банком разрабатывается, и ПО не покупается (покупается сервис), и не разворачивается на стороне банка... Один сплошной диссонанс :-)

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

LANDesk покупает LetMobile

А вот еще пропущенное поглощение :-) Тоже в мае, а точнее 21-го. LANDesk приобретает игрока сегмента мобильной безопасности - LetMobile, которая выпускала решения по защите мобильной почты, мобильному DLP, мобильному контролю доступа и т.п.