Secure Software Engineering

Аналитические материалы


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

Статьи перечислены в порядке их последнего обновления. Аналитические материалы могут и, я пока только планирую, будут обновляться по мере появления у меня новых идей и (главное!) моего желания их изложить. Таким образом можно предполагать, что статьи в этом разделе содержат более или менее актуальную информацию.

28 Октября 2017

Не только SDL

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

Что-то еще вспоминается? Думаю, я и здесь знаю ответ: нет не вспоминается. Очень маловероятно, что вы реально вспомнили что-то еще. Сейчас разработка безопасных программ прочно ассоциируется именно с SDL. Даже разработанный в прошлом году стандарт (ГОСТ Р 56939) практически полностью копирует эту методику; причем, на мой взгляд, это не самая лучшая копия.

Читать целиком

21 Декабря 2015

Дао безопасности

Хотите разработать безопасную программу — пригласите хакера.

Согласны с этим утверждением?

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

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

На основании своего опыта берусь утверждать:

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

Я предлагаю прочитать статью следующим читателям:

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

Читать целиком

17 Октября 2013

Когда «agile» (не) к месту

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

Статья состоит из трех частей.

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

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

Наконец, в ее третьей части я остановлюсь на проблемах «гибких» методик. Я покажу, как по мере взросления продукта в его разработку приходится вносить все больше элементов классики: планирования, документирования…

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

Читать целиком

25 Октября 2012

Риски и уязвимость

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

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

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

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

Читать целиком

28 Мая 2012

Свойства безопасности

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

Как проявляются различные свойства безопасности, почему они нам важны? Несмотря на кажущуюся очевидность, далеко не каждый специалист (даже специалист!) может грамотно сформулировать ответы на эти вопросы. Обсуждению их и посвящена эта статья.

Читать целиком