Не только SDL

Дорогой наш SDL!

Когда разрабатывался SDL, он был почти революционной методикой. Я говорю «почти», потому, что про разработки 60-х, 70-х годов в этой области просто забыли; а в те времена было сделано немало. Но если забыть про эту оговорку, то SDL стал пиком, высшей точкой развития методик обеспечения безопасности программного обеспечения прошлого века. Об этой истории можно написать отдельную целую статью, я не буду сейчас этого делать.

С тех пор прошло более десяти лет. Десять лет по меркам нашей индустрии — почти вечность; во времена разработки SDL картина мира настолько другой, что сейчас даже не верится.

И сейчас видны недостатки этой методики. Давайте их и обсудим.

SDL — крайне дорогое удовольствие. Мне в разговорах называли цифры затрат на его реализацию 10% - 30% от общей стоимости проекта. Это очень высокие затраты!

Так может оно того стоит? Может быть, за наши деньги получаем программы высокого качества?

Давайте посмотрим.

SDL основан на поиске уязвимостей. Мы анализируем программу или, лучше, проект программы, мы ищем в ней уязвимости и устраняем их.

Идея обеспечивать таким образом безопасность не нова. Она уходит своими корнями в начало 90-х годов. Тогда «хакеры» говорили: «мы посмотрим вашу программу, найдем в ней уязвимости, вы их исправите, а нам заплатите за работу».

Не сработало… Да, уязвимости искали, устраняли. Но меньше их не становилось, не успевали «хакеры».

Что делать? Умные люди подумали и сказали: «надо, чтобы „хакеры“ работали в штате компании, они будут иметь доступ ко всей документации, будет эффективнее искать уязвимости».

Не сработало. Все пошло по-старому. Да, уязвимости искали, устраняли. Но меньше их не становилось, не успевали «хакеры».

Что делать? Умные люди подумали и сказали: «давайте будем учить искать уязвимости самих программистов: их много, они знают свой код, они справятся».

Собственно, в этом суть SDL. Именно в таком виде его сейчас внедряют.

Помогло это? Судя по тому, что все больше компаний начинают внедрять программу «баг баунти», нет.

Баг баунти… Ой! А не с этого ли мы начали в начале 90-х?

Уязвимостей не должно быть изначально! Все, точка!

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

• разработать «плохую» программу;
• найти в этой программе уязвимости;
• оценить серьезность найденных уязвимостей;
• исправить наиболее опасные из найденных уязвимостей.

На мой взгляд, это глупость! Поясню почему.

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

Во-вторых, все уязвимости все равно найти не получится. Любой специалист скажет вам, что найти и исправить все ошибки в программе — дело практически невозможное. Да, теоретически… Но на практике, после того, как «собраны все низковисящие плоды», дальнейший анализ становится экономически невозможным.

В-третьих, даже найденные уязвимости не всегда устраняются. Мы все знаем золотое правило инженера, программиста: «если что-то работает, не трогай». Именно этому правилу зачастую следуют разработчики, откладывая исправление любой программной ошибки, включая уязвимости. Действительно, ведь все, кто занимался исправлением, знают: исправляя ма-а-аленькую уязвимость, можно создать бо-о-ольшие проблемы, в том числе и новые уязвимости. Поэтому в SDL есть такая шкала DREAD, и уязвимости, получившие низкие балы по этой шкале, не исправляются. Проблема в том, что при оценке по DREAD используются такие показатели, как наличие или отсутствие широко доступного «эксплойта» — весьма нестабильный показатель!

В-четвертых, привлекать всех программистов к обеспечению безопасности — это неэффективное вложение средств. Поясню:

• мы должны обучить всех программистов безопасности — это прямые затраты;
• мы заставляем специалистов (высококласных, высокооплачиваемых) тратить свое время на обучение вместо производства продукта — это косвенные затраты;
• специалисты вынуждены думать о безопасности, следовательно они меньше думают о своей непосредственной работе — еще косвенные затраты;
• они все равно не станут «хакерами» и не смогут искать все уязвимости — эффективность ограничена.

Причем, хочу отметить, ни одно действие в SDL не производит полезного продукта! Все действия — анализ и исправление ошибок, как следствие, все расходы на него — паразитные.

Вам все еще кажется, что внедрение SDL — хорошая идея?

Нужно ли платить за безопасность?

Хорошо, — скажете вы — SDL очень дорог, но за безопасность нужно платить! Сразу вспоминают пословицу «скупой платит дважды».

А я согласен! За безопасность платить надо! Только надо думать, за что.

Как я уже неоднократно отмечал, с момента создания SDL прошло много времени. Сейчас мы знаем гораздо больше, чем знали разработчики тех времен. И в частности, мы вспоминаем и переосмысливаем старые разработки 60-x, 70-х годов.

Так что же мы можем предложить сейчас?

Мы умеем создавать «естественно» безопасные программы. Сейчас есть все возможности использовать такие методы разработки, в которых уязвимости не создаются изначально. Уязвимостей не должно быть изначально! Все, точка!

Заметьте, все существенно упрощается. Действительно, мы избегаем всех этих плясок с анализом, поиском уязвимостей, оценкой найденных уязвимостей, планированием их устранения, устранения, нового тестирования…

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

«Это невозможно!» — скажете вы. И тем не менее, такие методики существуют, они описаны и даже есть опыт их применения.

Да, не существует решения на все случаи жизни. Каждая компания, каждый проект в чем-то уникальны, и для каждой из них надо находить свои подходы (а не рекомендовать, и уж тем более не требовать, реализации одной конкретной методики).

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

Опыт использования этого и других подобных приемов есть. … Есть такой опыт и у меня.

Упомяну здесь только об одном таком инструменте. Я выбрал его, поскольку, на мой взгляд, он крайне эффективен. Иногда я думаю, что это вообще самый эффективный прием, особенно в комбинации с другими.

Я говорю о разделении безопасности и бизнес логики.

Кажется, это очень очевидная идея. Вообще, разделение программы на части, которые могут разрабатываться относительно независимо — это самый используемый прием в разработке. Это один из первых навыков, которые получает программист; так, в книге для начинающих программистов на C++ «Accelerated C++: Practical Programming by Example» есть описание, как надо организовывать программу — четвертая глава из шестнадцати.

Разделение безопасности и бизнес логики может творить чудеса. Так, в идеальном случае, можно сделать, чтобы разработчики бизнес логики вообще не думали о безопасности: они могут творить вообще что угодно, и это не будет приводить к появлению уязвимостей. И это сразу снимает огромное количество наших расходов на проект (перечитайте предыдущий раздел).

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

Тем не менее, я видел очень мало проектов, где используется этот прием. Думаю, это связано с тем, что не многие понимают, как это делается. И это приводит к тому, что специалисты относятся к таким методам с недоверием.

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

Есть такой опыт и у меня. Мне довелось участвовать в качестве одного из ведущих разработчиков в проекте, где использовались близкие идеи. К продукту предъявлялись очень жесткие требования безопасности, поэтому и изоляция должна была быть очень серьезной; в этом смысле это был экстремальный проект. Но задача была успешно решена, а я многому на этом проекте научился.

Так что, можете быть уверены: подходы работают.

А что же с SDL, что с ГОСТ Р 56939? Стоит ли их забыть совсем?

Нет. Мероприятия, которые описаны в упомянутом стандарте, хорошо использовать для контроля качества полученного программного обеспечения. Это другое использование. Но подробности заняли бы очень много места.

Подробнее по теме

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

Для тех, кто хочет подробностей. Предлагаю вам почитать мою большую и подробную работу по этой теме. Сразу предупреждаю, работа очень большая (120 тыс. символов), даже не могу назвать ее статьей. В наше время редко кто читает такие длинные тексты, но прочитавшие есть, хорошие отзывы тоже есть.

В работе я неявно использовал модель «4П: проект, продукт, процесс, персонал». В частности, я проанализировал:

• что значит «безопасный продукт», что это за свойство «безопасность»;
• какой мы должны делать программу, чтобы она была безопасна;
• какие действия мы должны выполнить, чтобы получить именно безопасную программу;
• какими знаниями и навыками должны обладать специалисты, которые будут разрабатывать безопасную программу.

Большая и серьезная работа.

Будете ли вы это читать — выбор за вами.

«Legacy». Усиление существующих программ

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

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

Поэтому, теоретически…

Но поговорите с реальными разработчиками. Скорее всего, разговор о том, что надо с самого начала разрабатывать безопасные программы, очень быстро придет к заявлению разработчика: «но у нас уже есть программа, она внедрена, она работает!».

Мы очень редко разрабатываем программы «с нуля». Спросите любого программиста, довелось ли ему участвовать в таком проекте; с большой вероятностью ответ будет «нет». В подавляющем большинстве случаев нам приходится поддерживать уже существующие программы.

Что же делать? В SDL для этой ситуации используется «security push»: все разработчики на длительное время (неделя, месяц!) бросают всю свою работу, ищут и устраняют уязвимости.

Что я думаю об эффективности подобной практики, читайте выше.

Есть ли более эффективные методы? Есть.

SDL — старая методика. Как я уже неоднократно замечал в этой статье, она разрабатывалась очень давно по меркам нашей индустрии. Кстати, уже даже сама Microsoft пишет об SDL несколько по-другому, чем она это делала раньше.

За последнее время разработано множество методик. В том числе есть и технологии внедрения безопасности в уже существующие программные продукты.

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

Чем могу помочь я

Думаю, вполне естественным будет в конце подобной статьи предложить свою помощь в освоении и использовании этих новых методик.

Скажу сразу: я точно не смогу решить все ваши задачи в области разработки. Я не знаю гораздо больше, чем знаю: есть множество людей, которые знают и умеют больше меня в разработке программ; есть множество людей, которые лучше меня разбираются в безопасности.

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

Есть очень узкая область, в которой я действительно разбираюсь.

Я могу научить разрабатывать безопасные программы. Я могу разработать учебные материалы, руководства, провести тренинги.

Это я умею.

Я могу сделать исследовательскую и/или аналитическую работу в этой области. Это я тоже умею.

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

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

Если говорить о непосредственном участии в проекте, я могу быть полезен в таких работах:

• начальное планирование проекта с учетом необходимости создания безопасного продукта;
• консультирование разработчиков в ходе исполнения проекта;
• определение требований безопасности к программному обеспечению;
• проектирование функций безопасности;
• оформление требований программы в соответствии ГОСТ Р ИСО/МЭК 15408 (ISO 15408, Common Criteria) (рекомендация ГОСТ Р 56939)
• разработка архитектуры программы (именно здесь мы разделяем бизнес логику и безопасность и делаем еще много разных интересных вещей);
• разработка критических участков кода;
• планирование мероприятий по контролю отсутствия уязвимостей в продукте в соответствии требований ГОСТ Р 56939;
• участие в анализе результатов уже завершенного проекта, и разработке рекомендаций по улучшению использованной методологии.

Немного подробнее о себе я написал на специальной странице.

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

Буду рад поучаствовать. Приглашайте.