Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Дмитрий Истомин (УЦСБ): элементарная безопасность web-приложений

Выступление Дмитрия Истомина (УЦСБ) на Неконференции *aaS предпринимателей 2011.

Думать об элементарной безопасности приложения — это как руки мыть перед едой, должно быть на уровне привычки. Самое эффективное для создания безопасного приложения — закладывать требования на этапе проектирования. Рассмотрим на примере некоторых продуктов различные подходы к ИБ.

Презентация

Видео

Стенограмма

Cкачать .pdf

Я — директор по развитию компании Системные Интеграторы, которая занимается информационной безопасностью профессионально. Если подходить классически, классический подход, то безопасность приложений — это довольно просто. У всех есть какое-то приложение. Компания хочет, чтобы оно было безопасно. Сверху там что-то такое накручивается, система безопасности так называемая. Все хорошо. Но с течением времени становится все сложнее и сложнее идти по такому подходу. И, вот, я думаю, что мы сейчас обсудим, как вообще совместить эти две задачи. Во-первых, построение доступного удобного сервиса, как сказали в предыдущем докладе, что будущее за SaaS, и как сделать все-таки безопасным. Кроме того, как уже упоминалось, проблемы безопасности, доверия стоят достаточно остро.

Во-первых, определения. Что такое вообще безопасный сервис? Вопрос, вообще, не праздный, потому что под безопасностью можно понимать абсолютно разные вещи, иногда, даже, противоречащие друг другу. Во-первых, сервис — это традиционно автоматизация какого-то процесса. Думаю, это не вызывает сомнений. Процессный подход, с ним достаточно все знакомы, и рассматривать автоматизацию сервиса достаточно удобно с этой точки зрения. Будь то электронная почта, будь то бухгалтерия, заказ по интернету пиццы — это все процессы. Тогда, безопасный сервис — это безопасная автоматизация бизнес-процессов. Логика. И, на самом деле, достаточно часто встречается именно такая трактовка.

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

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

Здесь получается такое противоречие, сейчас вот о нем поподробнее. С одной стороны, безопасно — это риски, связанные с использованием этого процесса, который мы используем. Риски приемлемы, ну, некий риск. С другой точки зрения, безопасно — это значит, я получаю от системы именно то, что ожидаю, и только это. То есть, нет каких-то непредсказуемых для меня последствий. И в данном случае посмотрим пример. Происходит событие. На какой-то сервис происходит оплата телефона или вообще оплата чего-либо. Является ли функцией безопасности возможность отмены платежа? То есть, если у нас, вдруг, проводится какой-то неправильный платеж, неправильный с точки зрения нелегитимный, то с точки зрения пользователя, вообще, хорошо бы уметь его откатывать, а с точки зрения владельца системы такая возможность лишь добавляет рисков. То есть, требования пользователя и требования владельца системы в данном случае вступают в противоречие. Если владелец думает о своих рисках, он сделает, чтобы платеж возвратить нельзя было. Если же владелец клиенто-ориентирован и хочет удовлетворить пользователя, то, как раз таки, и включается возможность отмены этого платежа.

Этот стык потребностей и интересов достаточно важен. Как показывает практика, в тех сервисах, которые сейчас используются, вот, для меня наиболее родные сервисы — это банковские. Мы потом поговорим, что сейчас с точки зрения безопасности идет обкатка на банковских сервисах того, что ожидает рынок SaaS в будущем. Потому что, естественно, все угрозы, в первую очередь, появляются там, где есть деньги. а деньги есть как раз в банковских сервисах в настоящий момент, и там ситуация вообще сейчас катастрофическая. Я об этом еще расскажу. То есть, у нас есть противоречие: для кого безопасно — для владельца или для пользователя?

Следующий такой риторический вопрос. А когда, вообще, нужно думать о безопасности? Вроде, работает сервис. Клиенты идут. Инцидентов нет. Все хорошо. Первоначально, естественно, речь всегда идет о функциональности. Во-первых, если у нас услуга или сервис связан с деньгами непосредственно, то в настоящее время не на последнем месте стоят сразу же требования по защите. Здесь такие вещи как системы платежей PayPal, ASSIST, системы интернет-банкинга — дистанционного банковского обслуживания и так далее. То есть, сейчас эти системы первые отрабатывают на себе варианты, как можно защищать свой сервис.

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

Естественно, возникает вопрос, а как сделать все по-быстрому и без затрат? Тут ответ очень простой: «Никак!»

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

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

В то же время, для меня это остается загадкой, почему-то… Пример разработчиков программного обеспечения в банке. Уже давно производится автоматизация процессов в банках, и разработчики этого ПО никак не задумываются об элементарных требованиях по безопасности. Ну, об элементарных, конечно, задумываются, вход с систему по паролю и так далее, но, даже, минимальное какое-то внятное журналирование, защита журналов от администратора и так далее, какие-то базовые принципы, они реализуются только в последний год, вот, начали. Что же тогда твориться в системах, не связанных с обработкой денег? Я думаю, что там еще хуже, насколько я сталкиваюсь.

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

В качестве примера. Мы проводили аудит портала компании сотовой связи. Там тоже вполне себе деньги, есть свои риски и угрозы, но при этом подходы абсолютно незрелые. Получается, что вот этот класс приложений мы уже не можем просто взять и вот так огородить периметром, поставить человека с ружьем. Получается патовая ситуация. Приходят в банк и говорят: «Вот, вы знаете, у нас воруют деньги. Деньги воруют, просто, пачками. За последний год статистика просто ужасающая у нас в России, причем, в регионах. Там, сотни миллионов, просто, уходят». При этом, на те атаки, которые проводятся, нет вообще никакой возможности сделать полную защиту не переписывая целиком приложение.

В качестве примера. Все же пользуются, наверняка, интернет-банками? Как обычно проходит авторизация а вас в интернет-банке? Какие есть варианты?

Из зала: Sms приходит с паролем.

Одноразовые пароли. Еще? Авторизация либо по паролю либо по токину.

Из зала: Шифрованный сигнал.

Токин, просто пароль. Например, в Сити-банк, у меня есть, там один только пароль и все.

Из зала: Ну, почему? Они еще сессию проверяют. Там много систем защиты. Вы упрощаете. Можно получить пароль для авторизации, с помощью токина можно неплохо защититься. Проблема только в том, что они разрабатывают системы, однако, когда этих угроз не существовало. Они сейчас возникли.

Я не упрощаю. Этих угроз, это каких вы имеете ввиду?

Из зала: Хакеры не обращали внимания на банковские сервисы и не писали банковские трояны. Сейчас они начали писать.

Так. Сейчас ответа на вот эти трояны, по крайней мере, у нас в России вот эти системы никак не проверяются.

Из зала: Ну, почему вам не нравится? Ну, что вы говорите?

Давайте рассмотрим. Я готов поддержать дискуссию. Давайте какой-нибудь пример рассмотрим.

Из зала: Альфа-банк.

С одноразовыми паролями.

Из зала: То, что делает Альфа-банк постепенно, то, что делается Сбербанком постепенно. На них каждый раз появляется новый механизм взлома, и они делают эту «заплатку». Это обычные вещи информационной безопасности. Сделать полностью защищенный механизм клиент-банка теоретически не возможно. Можно доказать, почему так. Можно сделать частичную, сделать факторную экспликацию, постараться сделать так, чтобы управление компьютером нельзя было получить удаленно, сделать хороший механизм модерирования, сделать так, чтобы сам компьютер ни по портам другим не лез и к другим сайтам не обращался. Тогда более-менее можно сделать защиту. Если компьютер является компьютером общего пользования, там, ведь, не только клиент банка, но и другие ресурсы, то нормальную защиту нельзя построить теоретически. Только до определенного уровня.

На самом деле, все правильно. Об этом и речь. То есть, некое доверенное всегда, вот, некий банк. Почему я зацепился за этот пример? Потому что он самый явный и на SaaS очень похож. И здесь есть клиент.

Из зала: Многие клиенты банков построены на чистом SaaS.

Да. Есть клиент. И, если банк озабочен тем, чтобы сделать свой сервис безопасным, то вот этой части он может что-то сделать, а вот в этой части, то, что на стороне клиента, он сделать не может вообще ничего.

Из зала: Но, есть же OSS, Apenist, Befeed сделают нормальную систему, то будет хорошо. Просто, пока они не могут это сделать. Много денег это стоит.

Ну, пока, да. Пока не могут. И вот то, что последние атаки, которые вытаскивают, ну, обходят факторную идентификацию с помощью паролей sms.

Из зала: Идентификацию они обходят с помощью удаленного управления компьютером. А факторную идентификацию при помощи sms они не обходят.

Обходят.

Из зала: Они получают sms. Говорят, что sms не прошел и его используют. Они, просто, делают атаку, когда человек видит, что sms получил и не использует, а, на самом деле, использует.

Я проговорю схему, просто, не все в курсе может быть и им это будет интересно. Атака типа MITB, которая в последнее время появилась, действует следующим образом. Есть компьютер, который у нас подключен к интернет-банку. Есть пользователь. Есть web-бугаи, как обычно. Происходит заражение компьютера, с которого пользователь выходит в какие-то интернет-банки. Написание специализированных троянов возможно потому, что сегментов мало. Большую часть рынка держат унифицированные системы. 2 системы у нас в России держат большую часть рынка. Ну, сделали подобную систему. Троян охватывает, таким образом, сотни банков. Значит, произошло заражение. Дальше через социальные сети или каким-то образом еще находится номер телефона этого человека и заражается еще его телефон. В конкретном примере с этим вирусом очень хорошо заражался телефон Nokia, потому что была подделана подпись магазина Nokia. Пользователь получал на телефон приложение, и у него, даже, не возникало вопросов надо ли ставить это приложение. Дальше все просто. Клиент идет в банк. Хочет отправить платежку. Заходит на сервис банка. Заполняет там некую форму какими-то полями, естественно, там сумма и номер счета. То есть, это основные параметры платежа. Троян, которым у нас заражен компьютер, эти поля подменяет, показывает пользователю одно, а в web-банк уже отправляет другое. При этом, даже, если используется токет с ключом, который невозможно вытащить из токинговой системы с криптографией на порту, при этом все равно пользователь говорит ОК при подписании платежа и этот момент обходится. Вот и все, гарантированный способ авторизации по токингу. Дальше банк отсылает sms пользователю для того, чтобы по второму каналу, дополнительному, платеж подтвердить. В это время на телефоне, естественно, также троян ловит эту sms, а пользователю ничего не показывает, и пересылает ее злоумышленнику. Злоумышленник подтверждает платеж уже свой, и платеж уходит куда нужно. При этом, особо виртуозные системы еще умеют подделывать выписку из банка. То есть, пользователь, даже формируя выписку, все равно видит то, что он хотел увидеть. Ну, вот это такое последнее изобретение, от которого достаточно сложно, по сути, защищаться.

Из зала: Да, просто, воруют ключи и потом ddos-ят клиент банка пользователя. Полдня прошло и все нормально.

Процент таких атак все-таки сокращается. Мы статистику с Управлением К собирали и в России зафиксировано таких случаев 5 различных вариаций. Я к тому, что смотрите. Вот эти технологии, которые хакерами обкатываются на банковских системах, потом будут использоваться везде. Процесс монетизации взлома банков сейчас, просто, на порядки выше. Из-за этого никто не смотрит на простые сервисы. То есть, сейчас очень серьезные деньги — это международные платежные системы, там очень большие объемы, и взлом систем ДБО. Как быстро это переключится на другие части — это не понятно. Но, необходимо все-таки готовиться.

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

Давайте рассмотрим некий пример, как это сейчас можно все делать и как, по крайней мере, мы сейчас пытаемся делать при анализе приложений и web-сервисов. Есть некая модель сервиса, строится, состоящая из внешних посредников, которыми могут быть клиенты, какие-нибудь внешние по отношению к исследуемому сервису сервисы. Есть у нас непосредственно процесс. Процессов может быть у нас много. Есть хранилище данных. И есть некая граница доверия. При этом, внутри границы доверия мы можем себе позволить некие вольности. То есть, какое-то более доверенное функционирование и обмен данными. Все что у нас за границами доверия, к этому следует относиться гораздо внимательнее. Я думаю, что тут все в курсе страйк-модели? Нет. Давайте тогда разберем.

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

Есть некая страйк-модель, согласно которой можно построить исчерпывающую модель угроз. В чем еще проблема? Мы можем задуматься. Вот, у нас есть сервис доставки пиццы или заказа каких-то более существенных услуг. Мы проводим оценку рисков. Как мы ее проводим? сели и думаем. Вот, у нас пользователь может заказать сначала пиццу и дать неправильный адрес. Это угроза? Угроза. Сервис отработает неправильно. Либо он может как-то неправильно сделать заказ и заплатить меньше денег. Какие-то такие вещи все равно продумываются базово. Мы написали, пусть, 100 таких угроз. Могу сказать, исходя из практики, что для каких-то не очень больших предприятий до 500 тысяч человек модель угроз для автоматизированной системы получается порядка 500 актуальных угроз. Но, нет абсолютно гарантии, что вы ничего не упустили. Как вот это понять? Ну, хорошо, вот тут мы придумали, а вот тут даже не знали, что такое вообще может быть, что вообще бывают такого рода атаки. Это, на самом деле, очень большая проблема — обоснования полноты модели угроз. Ну, вот, существуют различные методы. В частности, использование страйк-модели.

Существует 6 типов угроз. Первое, подмена идентификатора. Что это означает? Это означает, что, пусть, Иванов Иван Иванович у нас в сервисе как-то логинится, как-то он там живет, что-то делает. И какова вероятность, какие возможности у Сидорова Виктора Васильевича зайти под логином и представиться Ивановым Иваном Ивановичем? Утрированный пример. Если у нас, просто, человеку нужно ввести логин, сказать, что я — это я, или это, например, авторизация по IP адресу, которая ведет к таким уязвимостям, то угроза эта достаточно высока.

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

Из зала: Ну, вот те же злоумышленники, они ведь данные о себе постоянно искажают.

А кто искажает?

Из зала: Сами пользователи.

Это тоже угроза безопасности, и ее тоже надо рассматривать. Просто, у вас в системе есть разные роли. Есть, там, роль «пользователь», «оператор», «администратор». И каждая такая роль вызывает свой тип угроз.

Из зала: Это как с уборщицей, которая здоровый зуб девочке вырвала. Это тоже вопрос угрозы безопасности.

Следующая угроза — отказ от авторства. Это очень популярная в свое время была угроза как раз для интернет-банков. Когда пользователь отправляет платеж в клиент, потом говорит, что это не он, верните деньги назад. Угроза вполне себе явная.

Из зала: Вот, правда, что просят владельцев машин солодянцев645, если есть такие машины, если есть такие машины, то их перестраивать? Здесь нет такого?

Вполне, ничего страшного. Отказ от авторства. Причем, когда это связано с деньгами, явно понятно, что это вызывает какие-то неприятности. Вот, сегодня столкнулся с сервисом заказа такси. Заказал 2 такси. Одно пришло, второе пришло чуть позже, а я сказал, что не вызывал. Понятно, что штрафных санкций ко мне никаких не применить. Единственное, там, занести мой номер телефона в черный список. Но, тем не менее, компания какие-то убытки для себя понесла. Время затрачено, бензин, водитель недоволен и так далее.

Утечка информации. Такое классическое понимание безопасности — нарушение конфиденциальности данных. Здесь на нем останавливаться даже не будем.

Блокирование доступа. Могу сказать, что на данный момент это самая неприятная угроза, с которой совершенно непонятно, что делать. Думаю, что те, кто сталкивались, те понимают, о чем речь. Если для снижения риска по другим угрозам гораздо большая эффективность вложения средств. То есть, по этим 4 или по последней можно вложить, условно говоря, 5000 долларов и снизить риски условно до 5%, то в защите от блокирования доступа можно вложить 50 000 долларов и получить вероятность 30%.

Из зала: Такая защита доступна только для больших проектов и больших компаний с большой суммой денег.

Более того, есть еще обратная сторона медали. Организация вот этой атаки очень дешевая.

Из зала: Вы ddos имеете ввиду?

Да.

Из зала: Например, пришли из Моссервиса и сказали, а дайте вот такому сервису денек не поработать.

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

Строится в итоге вот такая штука. То, о чем мы говорили. Есть карта нашего сервиса. Вот модель нашего сервиса. И каждый из этих вот информационных потоков мы должны оценить, а насколько вот это взаимодействие безопасно по страйк-модели? То, что выделено красным, значит — угроза актуальна. То, что черным — пока все хорошо. Что дает эта страйк-модель? Она дает некую уверенность, что модель угроз получается полной. Если все 5 угроз проверить на всех информационных потоках, то это уже неплохая работа. Что у нас находится внутри границы, мы вполне можем себе позволить вот эти риски. Что у нас находится за границами, нужно срочно с этим что-то делать. В этом примере, во-первых, нужно понимать, что делать со связью с хостом и со связью с базой данных. И дальше уже по каждой вот этой букве мы рассматриваем, а что мы можем сделать, чтобы снизить вот эти наши риски?

Еще один, наверно, самый полезный подход из тех, которые мы используем — это Secure Development Lifecycle. Кто, опять же, хорошо знаком? Тогда стоит, действительно, записать и проникнуться. методика разработана компанией Microsoft как раз в период, когда у них с безопасностью все было плохо. и сейчас они по этой методике спокойно живут. Кроме того, они эту методику опубликовали, несут в массы. Тут они, я считаю, молодцы.

О чем идет речь? Разработка любого сервиса у нас состоит из нескольких стадий. То есть, они не открыли ничего нового. На самом деле, это тот же самый цикл Деминга — это SaaS-цикл, который у нас в стандарте качества. просто, он более адаптирован под разработку. Сначала у нас идет формирование требований — стадия формирования требований. Второе — это проектирование. Как раз таки на этапе проектирования у нас идет оценка рисков, построение модели угроз. То есть, мы придумали какую-то модель своего сервиса, архитектуру. Еще не начали его реализовывать. Дальше мы эту архитектуру нарисовали и посмотрели, а что у нас там, вообще, с рисками? Посмотрели. Хорошо. С рисками все не очень хорошо. Как нужно менять модель? Понятно, что менять на уровне архитектуры, на уровне модели, все-таки проще, чем на уровне реализованного кода. Это основное, пожалуй, правило, которое необходимо выполнять. Задумываться о требованиях безопасности необходимо на этапе проектирования. Реализация — это разработка кода. Здесь, естественно, связаны свои угрозы с правильной реализацией. Интересно почитать у того же Microsoft или Google про различные методы тестирования кода. Например, такой метод тестирования — Fusing. Когда берется приложение и на входы этого приложения кидается случайная бинарная последовательность, какой угодно длины, различные варианты. Вот такой тест на стрессоустойчивость приложения. И показывает достаточно интересные вещи. Кроме того, там есть методики анализа кода и так далее. То есть, безопасность кода — это уже следующий этап. Следующее — это проверка. Скорее всего, так же на уровне проверки происходит верификация, что, да, код написан хорошо. И выносится некое суждение. Здесь что важно? Я думаю, что вы прекрасно понимаете, что если вы что-то пишете, то проверять самого себя очень сложно. Невозможно себя контролировать. Это все-таки должны быть как минимум разные люди. Если вы не умеете перевоплощаться и не страдаете шизофренией в последней стадии, то необходимо предусматривать наличие каких-то специально заточенных людей без профессиональной деформации, которые ищут, а что плохо. На самом деле, в больших компаниях тестеры у разработчиков как раз являются такими людьми, которые проводят проверку. Они выполняют проверку именно на уровне реализации. А, вот, насколько мы сталкивались с разработчиками ПО, людей, которые бы на уровне проектирования тестировали бы модель на стрессоустойчивость на уровне архитектуры, вот, это бывает, к сожалению, крайне редко. Из-за этого как раз таки и возникает неэффективность.

Следующий вопрос, который, я думаю, также актуален. Хорошо. Я — разработчик. Я проникся всеми этими темами, внедрил в себя методику SDL, сделал оценку рисков, написал. Все у меня, вообще, круто. Но, как мне это донести до пользователя? Вообще, когда я столкнулся с моделью SaaS в первый раз, мне стало интересно. Да, за этим будущее. Это классно и здорово. И мы совместно с партнером, они как раз на тот момент построили очень современный хороший центр обработки данных, мы подумали: «А давайте попробуем, что из этого получится?» Получилось следующее. Из всех услуг, которые предоставлял ЦОД, более востребованной являлось размещение теста на оборудование. Для того, чтобы затащить людей на хранение данных на чужих серверах, буквально единицы соглашались, и то со скрипом. То есть, даже инфраструктура как сервис достаточно тяжело внедряется. В прошлом году на конференции как раз владельцев ЦОД-ов обсуждалась тематика и была поднята некая статистика, что почему-то в России пользователи не доверяют. При этом выходят парни из Финляндии и говорят: «Да у нас нормально в России бизнес идет. Нам как-то верят. У нас данные хранят». Тем не менее, исходя из тех примеров, которые я знаю и пользования удаленного хранения данных, 70% — это все-таки хранение зарубежом. Вот они (иностранцы) и говорят, что у нас в России есть бизнес.

Из зала: В Голландии еще. Это, просто, дешевле. Хранение данных в Европе в 8 раз дешевле, чем у нас.

Я сталкивался с людьми, для них дешевле было не столь критично, а вот то, что оно «там», а не «здесь», было важнее. Что с этим делать? Я лично, честно, не знаю. Я считаю это огромным препятствием по пути развития вот той оси S-кривой, о которой был предыдущий доклад. Единственное, что хоть как-то обнадеживает, что здесь все-таки границы государств уже достаточно условны, в развитии рынков, и потащит, может быть, не застрянем. И все-таки, если идеализировать и подумать, а как можно решить этот вопрос? И как он решается в других местах?

Пользователь хочет быть уверен в 2 вещах. Первое, что архитектура безопасна, и что реализация заслуживает доверия. Он, конечно, не отражает разницу между вот этими двумя. Он, просто, хочет, чтобы было все хорошо. Но, мы-то понимаем, что это там. Что может повлиять на уверенность пользователя? Личный опыт и опыт близкого круга людей. Это традиционный механизм, когда идет вовлечение первых 5% людей, которые хотят все это попробовать. Ну, и дальше это как снежный ком разрастается. Второе, это экспертная оценка, которой люди верят. Опять же, у нас специфика такая в стране, но, тем не менее, я на себе ощущаю пример такой доверия к экспертной оценке. Вот, я люблю сгущенку. Я знаю, что есть сгущенка, которая сделана по ГОСТу, и она вкусная. Если на сгущенке написано, что она сделана по ГОСТу, то есть, есть некая экспертная оценка, то я ее покупаю, потому что я не могу все попробовать и купить только ту, которая мне понравится. Когда существует проблема большого выбора и невозможно все попробовать, вот, и возникает методика, что либо друзья посоветовали, первый вариант, тоже своего рода экспертная оценка, либо обзоры в интернете читаем.

Из зала: А есть какие-то специальные стандарты, типа, как PCI DSS (Payment Card Industry Data Security Standard)?

Да. Вот об этом мы сейчас и поговорим. Есть отличный, на мой взгляд, стандарт ISO 15408 Common Criteria. Знаете, да?

Из зала: Он слишком большой.

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

Из зала: Он для логики или под процессы?

Он для технологий. Сейчас мы до этого дойдем. Стандарту ISO 15408 Common Criteria у нас есть абсолютно идентичный ГОСТ 15408. То есть, это не просто зарубежный стандарт, он и на русском языке есть, можно почитать, всего страниц 500. Для чего этот стандарт? У нас есть три сущности: потребитель, разработчик и оценщик. Между ними необходимо наладить взаимодействие. Потребитель хочет выбрать какой-то товар. В нашем случае, это некая программа, некий сервис, некое программное обеспечение, которое разрабатывает разработчик. И пользователь хотел бы быть уверенным, что там все хорошо в плане реализации. ISO 15408 Common Criteria обеспечивает некий свод единых правил какого-то общего языка, на основании которого разработчик может сформировать требования, провести реализацию. Оценщик сможет оценить это соответствие. А пользователь, видя заявление разработчика: «Вот, вы знаете, что у меня сделано вот так вот. Спроектировано вот так вот. Вот такой профиль защиты». Дальше мы посмотрим, что это такое. Оценщик говорит: «Да, действительно, у него все вот так вот спроектировано». Пользователь смотрит на это, понимает, что это хорошо и делает выбор в пользу. То есть, это некий общий язык для этих товарищей.

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

Значит, разработчик у нас решает разработать какую-то систему, не важно, абсолютно, какую. У этой системы, как мы говорили, будут некие требования по безопасности. Во-первых, это функциональные требования, налагаются на функции, которые предназначены для обеспечения безопасности. Например, что это? Требования к идентификации, аутентификации, титул безопасности, применение шифрования, удаление временной информации. В общем, какие-то конкретные вещи. И требования доверия, налагаются на действия разработчика и оценщика. Во-первых, пользователь хочет быть уверен, что оценщик достаточно хорошо живет и все правильно делает, и что разработчик тоже не дурак, и после того, как продукт вышел, разработчик сможет его нормально поддерживать. Здесь у нас примеры какие? Это требования к процессу разработки, поиску уязвимостей, анализу влияния на безопасность, тестированию, реагированию, на сколько быстро выпускаются патчи и так далее. Понятно, что идеального программного обеспечения не бывает. Уязвимости будут появляться. очень важным критерием является, а насколько разработчик, вообще, в состоянии реагировать на такие инциденты?

У нас времени не много осталось. Предлагаю, кому интересно, просто, почитайте более внимательно.

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

Компоненты мы формируем в пакеты, если требуется, и у нас это все формируется в профиль защиты. профилем защиты мы можем, например, назвать… У нас есть определенная безопасная операционная система пользователя. У нас есть некие требования к операционным системам, сформированные из этих требований, и мы можем любую операционную систему проверять на соответствие. Windows, Linux, самописная операционная система, абсолютно любая. Профиль защиты абсолютно инвариантен.

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

В итоге. Как у нас процесс оценки происходит. Есть профиль защиты. Что такое профиль защиты в тех терминах, которыми мы оперировали ранее? Профиль защиты — это некий проект системы. Точнее, даже, требование к системе. Мы эти требования можем анализировать, достаточны ли они для минимизации тех угроз, которые мы в своей системе увидели? Внести профиль защиты в каталог. Есть каталог открытый профилей защиты. Там любой разработчик, вот, сделал свой профиль, отправил его в реестр, и им может пользоваться любой другой разработчик. Профиль защиты у нас проходит проверку, если все хорошо. Дальше, под конкретный продукт у нас выпускается задание по безопасности. Если профиль защиты, как уже говорилось, инвариантен относительно операционной системы, то в задании по безопасности уже устанавливается конкретика. Пример. Можно в открытом доступе посмотреть задание по безопасности на продукты Microsoft. Очень интересно. После того, как у нас оценивается задание по безопасности, то есть мы оценили архитектуру и требования к ней, мы оцениваем уже реализацию. И после этого мы уже выносим вердикт — все ли там хорошо, в системе?

Комментарии (0)