Анализ качества кода на Уральском форуме в Магнитогорске стал одной из самых актуальных тем - ему было посвящено целых 3 доклада и отдельные высказывания представителей ГУБиЗИ и ДРР Банка России. С точки зрения здравого смысла очевидно, что анализировать качество кода нужно. Это повышает стабильность, надежность и защищенность готового продукта. Но является ли это обязательным требованием или всего лишь пожеланием со стороны экспертов?
Как это ни странно, но это является требованием не в одном, и даже не в двух нормативных актах. Начнем с СТО БР ИББС 1.0 от 2010-го года. Раздел 7.3.5 гласит буквально следующее: "Также документация на разрабатываемые АБС или приобретаемые готовые АБС и их компоненты должна содержать описание реализованных защитных мер, предпринятых разработ чиком относительно безопасности разработки и безопасности поставки". Иными словами разработчик должен вести безопасную разработку и должен написать про это в документации на поставляемую АБС. Интересно, кто-то когда-то проверял наличие такого раздела в документации на приобретаемые АБС?
А еще у нас есть PCI DSS с его разделами 6.3, 6.5 и 6.6, посвященными как раз качеству кода, безопасной разработке и регулярному тестированию ПО на предмет требований стандарта PCI DSS и других лучших практик. И конечно же стандарт PA DSS, полностью посвященный вопросам разработки платежных приложений; особенно раздел 5. В отличие от СТО БР ИББС стандарты PCI DSS и PA DSS носят обязательный, а не рекомендательный характер.
Но это не все, что ожидает банковские организации и разработчиков платежных приложений в отношении обязательств по анализу качества кода. Вспомним Уральский форум. Заместитель начальника ГУБиЗИ Артем Михайлович Сычев поделился планами по развитию СТО БР ИББС, в числе которых разработка нового документа "Требования к банковским приложениям и разработчикам банковских приложений". Можно предположить, что данный документ включит в себя базовый набор требований к функциональности и процессу разработки платежных приложений, применяемых в российских финансовых организаций. Аналогичные планы есть и у Департамента регулирования расчетов - их озвучил заместитель директора ДРР Андрей Петрович Курило. Правда, ДРР идет чуть дальше ГУБиЗИ и предлагает не только установить требования к разработчикам платежных и финансовых приложений, используемых в рамках Национальной платежной системы, но и проводить оценку их соответствия (возможно, сертификацию) указанным требованиям.
Но значит ли все вышенаписанное, что только банковские приложения должны подвергаться дополнительному анализу на качество кода? Нет. Ведь у нас еще есть угрозы наличия недекларированных возможностей в прикладном и системном ПО, используемом в информационных системах персональных данных. С ними-то надо что-то делать? Но что? 16 ноября я уже мутил дискуссию на эту тему, в которой родилось необычно много комментариев и предложений. Часть из них, вполне вероятно, войдет в приказ по защите персональных данных. А иначе как бороться с тем, что так опрометчиво разработчики ПП-1119 включили в число угроз, с которыми надо бороться?
Выглядеть фрагмент приказа мог бы так: "В случае определения в соответствии с Требованиями к защите персональных при их обработке в информационных системах персональных данных, утвержденными постановлением Правительства Российской Федерации от 1 ноября 2012 г. № 1119, в качестве актуальных угроз безопасности персональных данных 1-го и 2-го типов дополнительно к мерам по обеспечению персональных данных могут применяться следующие меры:
Так что готовтесь, коллеги...
Как это ни странно, но это является требованием не в одном, и даже не в двух нормативных актах. Начнем с СТО БР ИББС 1.0 от 2010-го года. Раздел 7.3.5 гласит буквально следующее: "Также документация на разрабатываемые АБС или приобретаемые готовые АБС и их компоненты должна содержать описание реализованных защитных мер, предпринятых разработ чиком относительно безопасности разработки и безопасности поставки". Иными словами разработчик должен вести безопасную разработку и должен написать про это в документации на поставляемую АБС. Интересно, кто-то когда-то проверял наличие такого раздела в документации на приобретаемые АБС?
А еще у нас есть PCI DSS с его разделами 6.3, 6.5 и 6.6, посвященными как раз качеству кода, безопасной разработке и регулярному тестированию ПО на предмет требований стандарта PCI DSS и других лучших практик. И конечно же стандарт PA DSS, полностью посвященный вопросам разработки платежных приложений; особенно раздел 5. В отличие от СТО БР ИББС стандарты PCI DSS и PA DSS носят обязательный, а не рекомендательный характер.
Но это не все, что ожидает банковские организации и разработчиков платежных приложений в отношении обязательств по анализу качества кода. Вспомним Уральский форум. Заместитель начальника ГУБиЗИ Артем Михайлович Сычев поделился планами по развитию СТО БР ИББС, в числе которых разработка нового документа "Требования к банковским приложениям и разработчикам банковских приложений". Можно предположить, что данный документ включит в себя базовый набор требований к функциональности и процессу разработки платежных приложений, применяемых в российских финансовых организаций. Аналогичные планы есть и у Департамента регулирования расчетов - их озвучил заместитель директора ДРР Андрей Петрович Курило. Правда, ДРР идет чуть дальше ГУБиЗИ и предлагает не только установить требования к разработчикам платежных и финансовых приложений, используемых в рамках Национальной платежной системы, но и проводить оценку их соответствия (возможно, сертификацию) указанным требованиям.
Но значит ли все вышенаписанное, что только банковские приложения должны подвергаться дополнительному анализу на качество кода? Нет. Ведь у нас еще есть угрозы наличия недекларированных возможностей в прикладном и системном ПО, используемом в информационных системах персональных данных. С ними-то надо что-то делать? Но что? 16 ноября я уже мутил дискуссию на эту тему, в которой родилось необычно много комментариев и предложений. Часть из них, вполне вероятно, войдет в приказ по защите персональных данных. А иначе как бороться с тем, что так опрометчиво разработчики ПП-1119 включили в число угроз, с которыми надо бороться?
Выглядеть фрагмент приказа мог бы так: "В случае определения в соответствии с Требованиями к защите персональных при их обработке в информационных системах персональных данных, утвержденными постановлением Правительства Российской Федерации от 1 ноября 2012 г. № 1119, в качестве актуальных угроз безопасности персональных данных 1-го и 2-го типов дополнительно к мерам по обеспечению персональных данных могут применяться следующие меры:
- проверка кода системного и (или) прикладного программного обеспечения на отсутствие недекларированных возможностей с использованием автоматизированных средств (автоматизированная проверка кода);
- проверка кода системного и (или) прикладного программного обеспечения на отсутствие недекларированных возможностей без использования автоматизированных средств (ручная проверка кода);
- тестирование информационной системы на проникновения (пинтесты);
- использование в информационной системе системного и (или) прикладного программного обеспечения, разработанного с использованием методов защищенного программирования".
Так что готовтесь, коллеги...
Все верно с одной стороны и ничего нового с другой. Иногда полезно повторить и выделить очевидные вещи. Особенно для понимания тенденции куда все идет и тут я совершенно согласен с итоговым выводом. Но не в этом суть.
ОтветитьУдалитьА суть в том, что, как минимум, странно с завидной регулярностью упоминать одни компании, а при этом явно специально умалчивать об их прямых конкурентах. Тем более тебе об этом говорили ранее в коментах и не раз и ты их отлично знаешь - это, как минимум, странно для того, кто хочет себя позиционировать как "независимый эксперт". Вот только раньше это было только ПТ, а последние 3 мес - ПТ и аперкат. На лицо просматривается явная тенденциозность и ангажированность. И, конечно, возникают разные ненужные вопросы ...
Ведь куда красивее всегда упоминать связку явных прямых конкурентов, добавляя ДСЕК и Фортифай. И сразу бы вопросов не возникало. Ан нет.
"Нежнее надо, еще нежнее". То есть, конечно, это частный блог и туда можно писать вообще все что угодно и упоминать кого угодно, через "элегантное" слово "например" или даже без - блог то частный. Но со стороны это выглядит очень странно, особенно когда это происходит со странной и участившейся регулярностью в последнее время и когда об этом регулярно замечают в коментах. И тогда, конечно, вызывает большие вопросы "независимость".
Но, в общем, хозяин - барин.
А HP Fortify не есть прямой конкурент PT или Appercut. :)
ОтветитьУдалитьА причем тут ПТ и Фортифай? Говоря про аперкат, речь в целом о сегменте производителей систем анализа кода.
ОтветитьУдалитьНу да, фортифай и иже с ними код не анализирует и не является при этом абсолютным лидером мирового рынка в этом сегменте. Кстати, и у ДСЕК есть решение по анализу кода, правда только ABAP кода для SAP - один из модулей ERPScan, но это в данном случае не важно.
Опять маленький мальчик обиделся? Мы с тобой осенью вели дискуссию на тему анализа кода и ты жаловался, что это никому не нужно и никто этого не делает. Я тебе тогда еще сказал, что ты можешь взять эту тему на флаг и вперед с ней идти. Ты сказал, что нет.
ОтветитьУдалитьТеперь тебе демонстрируют, что небольшие усилия и эта тема может превратиться во "второй dlp". И тебе опять не нравится. А что ты публичного сделал, чтобы про тебя говорили в связи с этой темой? Ничего.
Руст, вон, про это постоянно говорит. ПТ тоже. И Женя Родыгин. На РусКрипто секцию готовят. Про них и написал. Да и конкретные проекты по этим компаниям и Fortify я знаю (от заказчиков). Про твои проекты, увы... На мероприятиях по анализу кода тебя тоже нет. И почему тогда я должен тебя упоминать? Кроме твоего плача, что вы тоже что-то делаете, нет ничего. Измени ситуацию и я про вас буду упоминать.
И к чему такие нервы. Я в данном случае говорил не про анализ кода - у нас тут и правда практически ничего нет. Я говорил про связки: ПТ - ДСЕК; Фортифай - аперкат. И не делай вид, что ты не понял о чем я и сдвигай фокус темы. Не выйдет.
ОтветитьУдалитьВообще же, когда нечего ответить по фактам, начинают переходить на личности, причем регулярно, при этом разбавляя все это различными оскорблениями. Ну тоже метод для настоящего эксперта.
Позволю себе банальные истины, может кому это поможет (ты же делал презу как стать звездой, чем я хуже :) ):
Рекомендация 1. Эксперт рынка должен быть объективен вне зависимости от симпатий или антипатий. Эксперт должен быть выше всего этого (бабла, дружеских компаний, симпатий). Объективность и независимость суждений - вот что прежде всего отличает любого Эксперта.
Рекомендация 2. Эксперту никогда не стоит переходить на личности и хамить окружающим, даже если ему не нравится их мнение.
Рекомендация 3. Эксперту не стоит авторитетно высказываться об областях, в которых он разбирается. Эксперт не должен быть снобом.
Все это прямо как из рассказа Джека Лондона из цикла про Соломоновы Острова - только сейчас понял на что это похоже :).
Да. В противном случае общая и последняя рекомендация для любого эксперта. Надо писать в начале, что это рекламный пост и вопросов нет. Тем более ты сам писал не так давно, что нормально относишься к платной рекламе в своем блоге. И я тоже к этом нормально отношусь. Когда это открыто и честно.
Просто надо уже определиться, это блог Независимого Эксперта или просто частный бложик, коих туча.
Рекомендация 3. Эксперту не стоит авторитетно высказываться об областях, в которых он НЕ разбирается. Эксперт не должен быть снобом.
ОтветитьУдалитьПропустил частицу НЕ :)
Илья, а зачем упоминать Дсек в заметке про анализ кода, если среди предоставляемых Дсеком услуг анализа кода нету?
ОтветитьУдалитьПочему же в ТЗ на разработку ПО нет требования? Одна из причин - заказчик не знает на какой набор требований стлаться...
ОтветитьУдалитьtoxa, Илья сейчас тебе ответит, что причем тут ДСЕК и анализ кода, когда он писал совсем про другое
ОтветитьУдалитьАнтош, ты прочти статью.
ОтветитьУдалитьВ частности:
"тестирование информационной системы на проникновения (пинтесты);" - а это мы и ПТ.
Но если даже на это не смотреть и говорить ТОЛЬКО про анализ кода, то я понимаю фортифай и аперкат с их средствами (мы то ладно - у нас только ABAP), но ПТ тут причем - у них вообще нет своего софта. А руками и чужими средствами и мы (если это не ABAP), и ПТ (наверное) проверяем и смотрим на код, когда его дают. Вот только дают не часто.
А вообще, конечно, Леша прав. То что я писал не имеет отношения к какой-либо конкретной теме и, в частности, к анализу кода или пентестам. Это довольно длительная тенденция в целом и это конечно, очень грустно, что мне пришлось это явно выделить - просто чаша терпения переполнилась. Ну, я уверен, что Леша все понял, внял дружеской критике и, наверное, сделает правильные выводы.
ОтветитьУдалитьНа самом деле нам всем нужен русский Шнайер (полутехнарь, полузаконник) - тут уж как не крути. И у Леши пока еще есть такой шанс им стать, если удасться пройти через медные трубы и вернуться на Большой путь Эксперта - пока еще не поздно. Главное помнить заповеди Эксперта.
Братья во анализе, не ссорьтесь. Я сталкиваюсь с тем, что большинство заказчиков и интеграторов имеет довольно приблизительное представление о предмете разговора.
ОтветитьУдалитьДавайте сделаем нормальное исследование, нарисуем модель угроз для различного типа приложений (веб, внутренние, SCADA), опишем методики исследования приложений, лучшие практики, базы знаний по уязвимостям. У каждого есть материалы, которые и так отдаем заказчиками, давайте соберем их и опубликуем, хоть от RISSPA, хоть от Банка России.
На раннем рынке чем больше игроков, тем быстрее растет рынок. Поэтому мы никогда не замалчиваем наличие HP Fortify, IBM Appscan, SAP Code Inspector, Virtual Forge, Veracode или Coverity - мы хорошо знаем, чем мы от них отличаемся. Давно написал для VC обзор рынка SAST-сканеров в России, надо просто его обезличить и издать, чтобы было понятно кто есть кто, что умеет, а что нет.
Кто образовывает рынок, тот потом его и осваивает, банально, но работает. Я проверял.
А кто ссорится? Илья пытается из меня Шнайера сделать. Хвала ему и почет за это. Зачем нам, правда, второй Шнайер я не знаю, но мало ли чего я не знаю. Мы, блоггеры, особенно эпические, имеем узкий кругозор в отличие от хардкорных экспертов.
ОтветитьУдалитьЗЫ. А анализ кода мы поднимем и разовьем. С ДСЕКом или без него. Тут уж все от ДСЕКа зависит
Шнайер нужен, это я точно говорю. Глядишь и сделаем, если чуть иронии и, главное, самоиронии подучим :). Ну и ругаться если отучим с переходом на личности - без этого вот точно никак. Тем более вот уже вполне начинает получаться - осталось только закрепить.
ОтветитьУдалитьА анализ кода только с ДСЕКом - куда уж без нас то.
Всех с праздником :).
Ты уж в своей компании расти Шнайера. И учи его. А я уж как-нибудь Лукацким проживу
ОтветитьУдалитьТо есть модель угроз и обзор технологий никто писать не будет :(. Ну я один...
ОтветитьУдалитьА я тебе док скучный зачем выслал...?
ОтветитьУдалить