После появления на pastebin сообщения о взломе одного российского VPN-продукта у нас Женей Родыгиным завязалась дискуссия на тему недостатков отечественной системы сертификации средств защиты. Но поскольку опыт у нас разный, то и к выводам мы пришли разным. Я сторонник мысли о том, что система сертификации, которая не проверяет работоспособность продукта и его защищенность, а при проверке НДВ не находит 0-Day, убога и ее надо менять. Женя отстаивал другую позицию. Ну да ладно.
А тут на DLP Russia 2012 зашла с коллегами речь о том, что не хватает в России аналога PA DSS - стандарта с требованиям к платежным приложениям. Но можно посмотреть и шире - не хватает информации по тому, как писать защищенные программы (SDLC). Microsoft иногда проводит такие мероприятия, но их явно не хватает на всю Россию. Да и требований таких нет; не говоря уже об отсутствии ответственности.
Но зато есть интересные цифры, которые сравнивают затраты на устранение ошибок в зависимости от этапа жизненного цикла продукта. Вот данные Forrester. Под X тут понимаются некие ресурсы - деньги, время, люди...
К разработке софта эти цифры имеют также прямое отношение. Хотя могут отличаться константы. Например, Fortify приводит такие расчеты (правда, не говорит откуда они взяты). Устранение 200 ошибок/уязвимостей на поздних этапах жизненного цикла ПО (тестирование и поддержка) обходится в 2 с половиной миллиона.
А устранение того же количества дыр на этапе кодирования и тестирования - всего в 500 тысяч.
У Fortify соотношение не 1 к 30, а 1 к 100. Но как говорится, выгода от внедрения SDLC и software assurance все равно налицо. Это если не оценивать ущерб от реализации данных уязвимостей, например, в КВО, то все равно экономическая целесообразность от этого есть. Еще бы посчитать такой эффект в рублях, исходя из наших реалей. Может Appercut посчитает?..
Кстати, помимо Appercut, который занимается облачным анализом кода на предмет его безопасности, Positive Technologies тоже предлагает услуги по анализу кода заказных приложений. И услуги эти на российском рынке (особенно банковском) набирают все большую популярность.
А тут на DLP Russia 2012 зашла с коллегами речь о том, что не хватает в России аналога PA DSS - стандарта с требованиям к платежным приложениям. Но можно посмотреть и шире - не хватает информации по тому, как писать защищенные программы (SDLC). Microsoft иногда проводит такие мероприятия, но их явно не хватает на всю Россию. Да и требований таких нет; не говоря уже об отсутствии ответственности.
Но зато есть интересные цифры, которые сравнивают затраты на устранение ошибок в зависимости от этапа жизненного цикла продукта. Вот данные Forrester. Под X тут понимаются некие ресурсы - деньги, время, люди...
К разработке софта эти цифры имеют также прямое отношение. Хотя могут отличаться константы. Например, Fortify приводит такие расчеты (правда, не говорит откуда они взяты). Устранение 200 ошибок/уязвимостей на поздних этапах жизненного цикла ПО (тестирование и поддержка) обходится в 2 с половиной миллиона.
А устранение того же количества дыр на этапе кодирования и тестирования - всего в 500 тысяч.
У Fortify соотношение не 1 к 30, а 1 к 100. Но как говорится, выгода от внедрения SDLC и software assurance все равно налицо. Это если не оценивать ущерб от реализации данных уязвимостей, например, в КВО, то все равно экономическая целесообразность от этого есть. Еще бы посчитать такой эффект в рублях, исходя из наших реалей. Может Appercut посчитает?..
Кстати, помимо Appercut, который занимается облачным анализом кода на предмет его безопасности, Positive Technologies тоже предлагает услуги по анализу кода заказных приложений. И услуги эти на российском рынке (особенно банковском) набирают все большую популярность.
Честно говоря, обсуждать ошибки наших СЗИ, "не выявленные" сертификацией по НДВ - это как пинать убогого. Может у конечно у меня карма такая, но из опыта работы с нашими средствами у них зачастую заявленные то функции в рабочей среде могут вызывать проблемы и неработоспособность, что уж говорить про ошибки и НДВ. Возникает ощущение постоянного бета-тестирования на конечных заказчиках, причем не дай бог он не купил техподдержку - так будет жить с ошибками, которые производитель устраняет оказывается только за деньги.
ОтветитьУдалитьАлексей, мы "ругались" немного на другую тему. Мое мнение по поводу НДВ такое: Проверки НДВ носят характер преимущественно относящийся к качеству реализации ПО а не безопасности ПО. Всякий, кто посмотрит открытые требования РД НДВ придет к такому же выводу.
ОтветитьУдалитьНа мой взгляд в плане безопасности ПО у нас три недостатка: 1 - отсутствие требований/рекомендаций по проектированию и разработке безопасного ПО; 2 - отсутствие процедур "Секюрити коде ревив" которые направлены на выявление уязвимостей в ПО; 3 - отсутствие норм по контролю и реагированию на уязвимости, которые выявляются в процессе эксплуатации проверенного ПО.
Ну и защищенность проверяется, так как функции защиты распространяются и на объекты самого сертифицируемого СрЗИ.
Ну а заниматься глубоким тестированием Разработчику ПО не выгодно (http://kaskadsecurity.blogspot.com/2011/08/1.html) плюс сложилась ситуация, пока он тестирует, конкурент выпускает продукт и снимает сливки!
Какбы например вот - http://dsec.ru/consult/mobile/ ну а ERPScan так вообще в автоматизированном режиме проверяет ABAP код и на уязвимости и на бэкдоры. А если не специализированные направления в общем то от заказчиков не то что кода а минимального описания для GreyBox не добиться зачастую, такчто пока народу както BlackBox привычнее к сожалению.
ОтветитьУдалить"2 - отсутствие процедур "Секюрити коде ревив" которые направлены на выявление уязвимостей в ПО." - Вот это конечно удивляет, интернет трещит от информации по тому как безопасно разрабатывать ПО, хоть тот же OWASP, не понимаю почему надо обязательно разрабатывать что-то своё, которое как обычно к моменту написания будет не актуально)
ОтветитьУдалить2 Alexander Polyakov
ОтветитьУдалитьНикто не говорит про разработку своего! Вспомним как у нас тяжело проходит даже перевод их подходов и внедрение...
И важный момент, ссылку давал - не хочет Разработчик глубокого SCR сторонними организациями потому как очень дорого, а ведь еще нужно исправлять! Возвращаться на этапы проектирования!
У себя ввести OWASP выгодно, НО только для зрелых компаний и продуктов с длиииииинным рублем на несколько лет. А у нас проекты и ТЗ окупаемость которых за пределами 1-2 лет летят в топку сразу ! Я потому и рисовал "калькулятор" (http://kaskadsecurity.blogspot.com/2011/08/1.html)
2 Евгений Родыгин
ОтветитьУдалитьЕсли бы потребителям СрЗИ не навязывали бы искусственно отечественные сертифицированные изделия, то ситуация в целом была бы иной.
А так - рынок такие вопросы прекрасно регулирует, а не система сертификации.
2 DOOM
ОтветитьУдалитьЯ тоже заблуждался про рынок! Покажи мне кто на рынке декларирует соответствие заявленному, кто готов на рынке заплатить за независимую оценку, вводить дополнительные средства контроля и т.п.
Нет никакого рынка! Производителю проще играть "крутостью" продукта в хипстерском смысле :) Ну и другие "методы"...
Вот когда будет рынок и зрелость и т.п. тогда...
Если бы так и было, то ни одной сертификации по CC мы бы не увидели - она целиком и полностью добровольная.
ОтветитьУдалитьА рынок? Давайте на DLP поглядим - их в "обязательную программу" пока не включили - пыжатся как могут, а клиент все равно смотрит придирчиво. Вот и приходится старательно повышать качество. Между прочим, отечественные DLP решения для конечных точек хотя бы не приводят к моментальному перманентному BSOD'у (в отличие от наших же СрЗИ от НСД) - это показатель
Алексей, добрый день! сперва немного критики: в том сообщении на pastebin нету информации о каком-то взломе! Там лишь информация из отладчика ядра, понятная для системных программистов(например программисты Infotecs'a могут по ней устранить уязвимости). Далее про сертификацию и тд: на мой взгляд уязвимость == закладка. НО! Уязвимость != НДВ, поскольку не существует методологий разработки гарантированно безопасного кода! так что тут всё очень просто и грустно :(
ОтветитьУдалитьтут мнения могут быть по любому утверждению и комментарию. Но я вот лично не согласен с Никитой.
ОтветитьУдалитьуязвимость != закладка.
Уязвимость - удаленная BoF in Heap c full ASLR/DEP на Win2008 не дает доступа. Хоть программно ошибка разрабом и совершена, но она была совершена не умышленно, поэтому доступ злоумышленнику не гарантирован и затруднен. Когда я слышу "закладка", мне больше кажется что речь идет и специально-оставленном потайном ходе. Типа бэкдор. Тогда НСД через эту закладку - гарантирован. То есть само определение "уязвимость" и "закладка" отвечают на вопрос причины возможности НСД используя данный программный продукт.
2 doom
ОтветитьУдалитьУточнимся CC или 15408...
Добровольность такая же как и СВТ 6,5 классов!
Дело в том, что для тех поделок, что не очень хорошо натягивается СВТ используют ТУ или ОК...
Потому как сертификаты равнозначны. Почему применялись ОК - для западных продуктов проще готовое ЗБ перевести! А доводилось видеть гибриды из ТУ и ЗБ с частичным переводом?! Выглядит бредовее некуда!
Вот когда "рынок" потянется в добровольные независимые системы сертификации аля КАСКАД за конкурентными преймуществами тогда и будет разговор ...
Женя, мы с тобой спорили вообще о том как убого устроена отечественная система сертификации, а не просто НДВ ;-)
ОтветитьУдалитьАлександр, да, вас я забыл упомянуть. Но отчасти потому, что заметка писалась после DLP Russia, а там ряд банков упоминал именно Appercut и PT ;-)
Nikita: То, что ты сделал - это и есть взлом ;-) К счастью, не все могут понять, что ты выложил на pastebin. У меня некоторые коллеги спрашивают - а как это использовать? Так что взлом, есть взлом ;-) И публикация факта об уязвимости. Но тут важен сам факт, а не детали.
Я тоже самое могу сказать про уязвимости в нашей продукции - они тоже регулярно публикуются. Но у нас есть четкая процедура Vulnerability Disclosure и процедура устранения. Т.е. процесс налажен. И в этом, собственно, отличие отечественных компаний от многих западных. Неузявимых продуктов не бывает - бывают продукты с отсутствующим процессом устранения уязвимостей
Не спорили а совместно вдохновенно углублялись в проблематику. Было бы о чем спорить... Да под вискарь... А так просто позвездели...
ОтветитьУдалить> Вот когда будет рынок и зрелость и т.п. тогда...
ОтветитьУдалитьРынок - это прежде всего потребитель. И когда потребитель станет требовать, производитель вынужден будет пойти у него на поводу. Но это дорого, и потому производитель заваливает потребителя дешевым Г в красивой упаковке и с помпой, в надежде все потом доработать, а отечественного потребителя прессует государство своими сертификациями. Рынок есть, но он извращенный.
2 Евгений Родыгин
ОтветитьУдалитьВообще, я говорил про CC и именно про добровольную сертификацию в международной системе сертификации CC - кто заставляет Cisco, RSA, Microsoft получать сертификаты по Общим Критериям? Формально - никто, для них это именно что рыночное преимущество.
На самом деле там тоже все не просто. Лаборатории по СС сейчас поменяли правила и смысла большого вкладываться в глубокую сертификацию по СС нет. Выше определенного ОУД сертифицироваться не перспективно - все вендоры уравниваются независимо от реализованного функционала
ОтветитьУдалить2 doom
ОтветитьУдалитьНу за международные - там своих тараканов вывести не вывести.
И заметим, от применения или имитации применения так называемых *** дыр, багов и ляпов примерно столько же!
Качество само по себе растет медленно, его нужно пинать со всех сторон чтобы иммунитет рос...
>Качество само по себе растет медленно, его нужно пинать со всех сторон чтобы иммунитет рос...
ОтветитьУдалитьДа на самом деле не все так плохо. Давайте посмотрим на путь, пройденный ПО хотя бы за последние 10 лет - если 10 лет назад про безопасность могли попросту забыть при проектировании, то сейчас мы уже говорим об ошибках реализации - все-таки это прогресс и достаточно серьезный.
Хорошо считается эффективность тестирования тиражного софта: меньше ошибок -> меньше нагрузка на поддержку. Известно сколько ошибок в среднем находит тот же Fortify, известна стоимость лицензии, и известна цена обработки одного инцидента в техподдержке - перемножай, складывай и дели. Именно про это цифры от Fortify, которые ты привел.
ОтветитьУдалитьКоллеги же в комментариях пишут в основном про аудит и сертификацию заказных систем, где стоимость и эффективность аудита, а также статистика убытков сильно зависит от типа софта и кучи других факторов.
А еще есть куча софта, который вообще пишется самими компаниями непрерывно, то есть апдейты идут потоком каждый день. Тут можно посчитать стоимость on-line сканирования, но стоимость сэкономленных на поддержке денег приходится брать с потолка.
Клево, что ты написал об этом позитивно. Сейчас все про это пишут в терминах "все козлы, кругом бардак, дыры кругом, регуляторы из прошлого века". Рынок ранний, вялый, нужно его растить, холить и нежить. Показывать успешные внедрения, делиться методиками безопасного программирования (как MS) и тестирования, базами уязвимостей и т.д. Работать с регуляторами, производителями платформ, контрактными разработчиками.
Если не считать себя самым крутым аудитором, а сосредоточиться на том, как создать спрос, то можно и мир чище сделать, и денег заработать.
Этот комментарий был удален автором.
ОтветитьУдалитьЭтот комментарий был удален автором.
ОтветитьУдалитьПо сабжу. Если мы будем говорить о MS/Cisco/Adobe - то дело там не в сертификациях. Просто у компаний, для которых безопасность это не формальное требование, а вопрос качества (да, даже у Адобе и МС), то там появляются соответствующие процессы, отделы и персонал. Компания готова потратить деньги, что бы нанять архитекторов ИБ, инженеров, менеджеров, что бы наладить процесс разработки безопасного кода. Вот и все. Всякие вендоры ДБО или СКЗИ - не готовы тратить на это деньги. Всякие Гуглы и Яндексы - готовы. При этом уязвимости, конечно, будут и у тех и у других, только вот у первых уязвимости будут такого уровня, которые находили в 90-ых, и никаких защитных техник в релизе предусмотрено не будет, например типа strcpy, memcpy/sql=select+"_GET['id']" - то есть дешевый треш, который выявляется в 70%-90% на стадии разработки. В приложении без поддержки ASLR/HTTPOnly (через дробь у меня бинарь/веб подход - для разнообразия...). Что бы найти баги в MS/Google - надо постараться уже, конечно ошибки бывают и простые - но они не на поверхности. В конечном счете это и называется "качеством" кода с точки зрения безопасности. И никакие сертификации тут вообще ни причем. P.S. может только PA DSS стоит особняком, за счет практичекой части и целенаправленного применения.
ОтветитьУдалить2 Alexey Sintsov
ОтветитьУдалитьСертификация (в широком смысле а не про регуляторов) может быть причем, если подтверждение процедуры проектирования и реализации безопасного кода будут играть на рынке...
Этот комментарий был удален автором.
ОтветитьУдалитьКоллеги, доброе утро!
ОтветитьУдалитьХотел бы прокомментировать некоторые моменты.
Конечно, лавинный рост стоимости исправления любого дефекта ПО в (в т.ч. безопасности) при переходе на каждую следующую фазу жизненного цикла продукта - вещь очевидная, этот график лично я вижу практически в каждой книжке по QA выпущенной с 90-х годов, в отчетах компаний типа IDC, так что здесь ничего качественно нового Forrester или Fortify нам не сказали.
На мой взгляд, нет смысла противопоставлять сертификацию, в частности внешний аудит кода (т.е. структурное тестирование, whitebox testing ) и контроль внутренних процедур и процессов разработки ПО (SDL и иже с ними).
Это все равно что считать,что внедрение ISO 9000 на молочном заводе и сертификация его по данному стандарту гарантирует постоянное качество кефира, которое он производит и отменяет необходимость любого внешнего мониторинга и химических экспертиз пищевых продуктов вообще.
Разумеется, это не так.
Ну или другая аналогия: ISO 27000 или например COBIT - это ведь не замена методологиям типа OSSTMM, а просто вещи другого порядка, из другой области, взгляд с другой стороны.
"хоть тот же OWASP, не понимаю почему надо обязательно разрабатывать что-то своё, которое как обычно к моменту написания будет не актуально)"
Евгений, уточните, пожалуйста:
OWASP - это десятки разнородных, разной степени готовности проектов в области безопасности веб-приложений.
Если говорить конкретно об OWASP ASVS и Code Review Guide, то они целиком и полностью заточены на специфику веб-приложений и ни на какую универсальность не претендуют. Вряд ли они подойдут для аудита кода embedded-систем или Desktop-приложений.
Не так давно по работе активно изучал мировую базу нормативных документов в области безопасности ПО, уязвимости, дефекты, процессы и т.п.
Коллеги, в отличие от penetration test, я так и не встретил нигде полной подробной универсальной методологии аудита кода (code review).
Подскажите, пожалуйста, если знаете.
Да, есть огромный CWE, с хорошей классификацией дефектов кода с примерами и маппингом на почти все остальные системы + строгий словарь Mitre по vulnerability theory
Да, есть CAPEC для описания угроз и методов возможных атак.
Да, есть хорошие coding гайдлайны но лишь по отдельным языкам программирования и платформам, и здесь речь идет скорее о secure programming, а не о процессе аудита
Да, есть гайдлайны по software assurance отдельных министерств США, Австралии (в основном военных), опять-таки очень узкие.
Можно вспомнить PCI DSS (требование 6.6 и иже с ними), думаю коллеги гораздо лучше меня знают насколько "подробно" прописан там процесс code review.
Разрабатывают очень интересный стандарт ISO/IEC JTC 1/SC 22 N 0000 Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use
Но опять-таки, это создание приложений, а не их аудит, это - частность и глобального документа в мире, в этой области сейчас нет.
Значит в любом случае нам придется делать что-то новое и полностью своё, но с оглядкой на мировой опыт (и хорошо бы с референсами на существующие международные стандарты и базы). Поэтому сертификация ПО нам нужна, вопрос лишь в том, как её проводить и по каким требованиям.
Ну и возвращаясь к отечественной нормативной базе:
ОтветитьУдалитьДа, наш РД по НДВ - морально устарел, да надо уходить от этого бессмысленного рисования матриц связей между функциями (подход родом из теории надежности)
Да, надо задавать требования покрытия кода.
Да, нужно приходить к системному, компонентному анализу ПО, начиная с модели угроз приложения (аналог Microsoft Stride) анализа интерфейсов, оценке attack surface, до подробного процесса application verification/code review типа OWASPовского, но расписанного для различных типов приложений, архитектур и т.п.
Да, нужно отдельно прописывать требования к анализаторам кода (с базой тестовых кейсов, как в проекте SAMATE), вводить национальные классификаторы типов дефектов ПО (типа CWE) и реестры уязвимости (типа NVD, OSVDB), "связывать" все эти базы и требования подробными гайдлайнами.
Хотелось бы всё это увидеть при своей жизни :)
Чтобы резюмировать: мне кажется, всё в первую очередь упирается в нормативную базу, ну и, конечно, контроль качества работы испытательных лабораторий.
Если это удастся развить, то будут регулярно находить 0-Day уязвимости, никуда не денутся :)
iNs: так напиши предложения по реформированию данного вопроса - готов закинуть регуляторам
ОтветитьУдалитьЭтот комментарий был удален автором.
ОтветитьУдалитьАлексей, извините,я забыл представиться:
ОтветитьУдалитьАндрей Фадин, компания "НПО "Эшелон", испытательная лаборатория и орган по сертификации.
Мои коллеги, и я готовили и отправляли свои предложения регуляторам по доработке нормативной базы ещё c начала 2000-х годов, раз 6 как минимум.
Сейчас также пытаемся активно способствовать развитию отечественной нормативной базы, поэтому спасибо за Ваше предложение, с удовольствием обсудил бы его в личной переписке.
Андрей - не вы одни отправляли и обосновывали. Но что делать, если даже организовать совместное сборище органов и ИЛ по текущим горящим вопросам не удается! Ведь дошло до того, что ИЛ вынуждена очень разный материал выдавать разным органам, учитывая "хотелки" каждого органа. Не говоря уже о том, что Федеральный орган имеет свое мнение и иногда не принимает результаты пройденные экспертизу в органе.
ОтветитьУдалитьВ части предложений есть проблема - согласия нет, нет сборищ для обсуждений, все конкурируют. И это приводит к скептическому отношению по любой инициативе потому что она воспринимается исключительно как разработка НМД под себя для получения конкурентных преимуществ.
Вы то понимаете о чем я ;)
Если организация в системе не сдвинется то остается действовать через "рынок" формируя нормативку по принципу "Де факто"... Чем некоторые и занимаются...
iNs/Andrey, а по пен-тесту встречали "подробную универсальную методологию " ?
ОтветитьУдалитьВторое - я согласен про "пинание убогого". Пустая затея. Не верю в успех)
Alexey Sintsov пишет...
ОтветитьУдалитьiNs/Andrey, а по пен-тесту встречали "подробную универсальную методологию
3 самых известных:
OSSTMM, the Open Source Security Testing Methodology Manual.
The Information Systems Security Assessment Framework (ISSAF)
есть еще NIST SP800-115 но стар и малоуниверсален