Secure Software Engineering

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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