Безопасность приложения: это почти просто

    simple science

    — Дай мне справку, что моя программа безопасна.

    — Нет проблем! А что ты для этого делал?

    — Э… Ну… Это… Ничего…

    — А почему ты тогда думаешь, что она безопасна?

    — Ну, ты проверь!

    — Нет проблем! Все удовольствие будет стоить X0000 долларов.

    — ?!

    О статье


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

    Первая ее часть посвящена безопасному программированию.

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

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

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

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

    Внимание! Статья большая и подразумевает внимательное прочтение.


    Часть I. Безопасное программирование


    Знайте свои технологии


    У каждой технологии есть две стороны. Одна сторона — свойства, полезные нашему пользователю, мы используем их в своих продуктах; вторая сторона — свойства, которые может использовать взломщик, слабости технологии. Иногда технология слаба настолько, что ее использование нельзя оправдать ни при каких условиях. Например, функция gets в программе на C — практически всегда зло. Другие технологии использовать можно, принимая необходимые для защиты меры. Так использование SQL сервера потенциально может открыть возможность для sql injection. Но мы знаем, как с этим бороться и просто должны предпринять необходимые меры защиты.

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

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

    В интернете сейчас есть несколько хороших ресурсов, посвященных этой теме.

    Один их таких ресурсов — «The Open Web Application Security Project». Как следует из названия, проект посвящен безопасности веб приложений, однако эту же информацию можно применять и при программировании в других областях. Сайт сделан в популярной сейчас форме википедии, и состоит из отдельных статей; есть списки этих статей, сгруппированные по разным принципам. Указатель на статьи, сгруппированные по технологиям, можно найти по следующему адресу.

    Я и дальше буду неоднократно ссылаться на OWASP. Этот проект — очень ценный ресурс для специалистов, занимающихся безопасностью приложений.

    Очень хорошим источником информации может послужить сайт Common Weakness Enumeration. Сайт содержит интересную нам информацию в виде каталога, в котором перечислены причины возникновения уязвимостей в программном обеспечении. Воспринимается он сложнее, чем OWASP, но может оказаться более удобным, например, при формировании списков проверки.

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

    Используйте библиотеки


    Не изобретайте велосипед! Конечно, всем нам очень интересно сделать что-то свое. Но в безопасности изобретательство приводит к очень неприятным последствиям, поэтому используйте проверенные средства.

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

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

    Веб программистам, использующим Java EE, может понравиться ESAPI. Эта библиотека создана в рамках уже упоминавшегося здесь проекта OWASP, она реализует множество методов, необходимых для создания безопасных веб приложений. В библиотеке присутствуют функции, осуществляющие фильтрацию входных данных, аутентификацию пользователя, проверку прав доступа, и многое другое. Код лицензирован под BSD лицензией, допускающей очень широкое использование.

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

    Возможно, имеет смысл обратить внимание и на другую библиотеку для JAVA, Coverity Security Library. Библиотека была выпущена в конце прошлого года и пока отзывов о ней не так много. Тем не менее, создана она известной в области безопасности приложений компанией, и, можно надеяться, они понимают, что делают.

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

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

    В безопасности вообще так: меньше велосипедов — лучше решение.

    Делайте самопроверку


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

    Остановитесь. Когда вы только написали свой код, еще до его компиляции, сделайте небольшой перерыв, отдохните, забудьте про код. После перерыва посмотрите на написанное с разных сторон: проверьте синтаксис, соответствие кода корпоративному стандарту; проверьте логику кода; проверьте его соответствие требованиям безопасности («знайте свои технологии», помните?).

    Вы сэкономите много времени. Хотя, кажется, что время теряется зря, оно вернется за счет существенного сокращения отладки приложения.

    Самопроверка является признанной практикой создания качественного ПО. Так она включена в PSP (Personal Software Process), процесс, разработанный специально для создания качественного продукта в условиях жестких временны́х и финансовых ограничений.

    Обратите внимание: суета — враг не только качества, но и быстроты.

    Используйте утилиты проверки кода


    Человеку свойственно делать глупые ошибки. При этом все программисты знают, что именно глупые ошибки труднее всего обнаружить: какая-нибудь непоставленная точка с запятой может привести к потере целого дня (если не больше).

    Человеку сложно помнить все сразу. Для уязвимостей существует огромное количество причин; чтобы избежать проблем, надо помнить их все, надо проверять программу на их наличие. Более того, взломщики не стоят на месте: то, что считалось безопасным вчера, сегодня уже может быть уязвимо.

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

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

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

    Тестируйте


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

    Такое поведение может быть протестировано. И мы получаем все преимущества автоматизированного тестирования программы: его можно проводить часто, практически без участия человека.

    Не буду здесь давать никаких ссылок. В тестировании безопасного поведения нет никаких особенностей по сравнению с обычным функциональным тестированием. Вы можете использовать все свои наработки, включая TDD, непрерывную интеграцию, и все остальное, что вы знаете лучше меня. Конечно, вы должны уметь описать безопасное поведение (опять, «знайте свои технологии»).

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

    Тестирование не может решить всех проблем безопасности. Но если что-то возможно протестировать автоматически, почему этим не пользоваться?

    Делайте code review


    Ревизия кода — самый эффективный способ обнаружения ошибок. Причем он наиболее эффективен как с точки зрения количества обнаруживаемых дефектов, так и с точки зрения стоимости (времени) их обнаружения. Так Стив Макконнел в своей книге «Совершенный код» приводит ссылку на исследование компании IBM, в котором обнаружили, что один час, инвестированный в ревизию кода, сохраняет до 100 часов тестирования и устранения ошибок. Хотя я думаю, что число 100 будет достигаться очень редко, тем не менее, это очень хороший повод задуматься.

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

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

    И опять OWASP. Конечно, этот проект не мог обойти такую важную методологию стороной. Поэтому, если вы собираетесь проводить ревизию кода в своем проекте (я вас еще не убедил это делать?) соответствующая страница этого сайта — хорошая точка для старта.

    Так вы еще не делаете code review? Нет вам прощения!!!

    Используйте все меры в комплексе


    Э… Здесь что-то надо писать?

    Часть II. Проектирование безопасности


    Мотивирующая аналогия


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

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

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

    Серьезная ли это проблема?

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

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

    Программа в 1 миллион строк. Здесь все очень сложно: можно сильно упереться и решить задачу, но может оказаться быстрее и дешевле выбросить весь код и написать заново.

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

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

    А теперь вернемся к безопасности.

    Принципы безопасных архитектуры и дизайна


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

    Давайте я напомню эти принципы:

    • простота механизмов (economy of mechanism);
    • безопасность по умолчанию (fail-safe defaults);
    • полное проникновение защиты (complete mediation);
    • открытый дизайн (open design);
    • разделение полномочий (separation of privilege);
    • минимум привилегий (least privilege);
    • минимизация разделения ресурсов (least common mechanism);
    • психологическая приемлемость (psychological acceptability).

    Эти принципы были сформулированы почти 40 лет назад в статье “The Protection of Information in Computer Systems”. Сейчас к ним любят добавлять еще несколько правил (пример), но факт тот, что эти принципы известны уже давно, и они остаются верными до настоящего времени. Есть и примеры удачных решений, построенных в соответствии с этими принципами.

    Казалось бы, проектируй себе на здоровье, людям на безопасность.

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

    Мы должны использовать шаблоны.

    Шаблоны безопасных архитектуры и дизайна


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

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

    В программировании хорошо известны design patterns. Это шаблонные решения задач, возникающих при проектировании программ. Их использование существенно упрощает нам жизнь: надо привести стоящую перед нами задачу к стандартной, и применить уже имеющееся, заведомо работающее решение. Поэтому книга «банды четырех» — практически обязательное чтение для любого программиста.

    Шаблонами проектирование дело не ограничивается: шаблоны существуют на всех уровнях. Есть шаблоны архитектуры (вспомним, хотя бы MVC), есть шаблоны написания кода, есть шаблоны пользовательского интерфейса, есть шаблоны поведения программы. Практически на каждую возникающую задачу есть свои шаблонные решения.

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

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

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

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

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

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

    Первая публикация — «Security Design Patterns» (pdf). На мой взгляд, это одна из самых качественных публикаций, посвященных структурным паттернам безопасных программ. Она была опубликована почти 10 лет назад, в 2004 году консорциумом Open Group. В этой публикации вы найдете как методику проектирования безопасности с использованием шаблонов, так и описание многих из них.

    Например, очень интересно описание шаблона «Protected System». В других источниках он более известен, как «Reference Monitor», и очень часто упоминается в литературе. Но, чаще всего, именно упоминается: в большинстве других публикаций ему посвящается от силы полстраницы. В работе Open Group использование шаблона «Protected System» разбирается очень подробно, в том числе продемонстрированы возможные варианты его использования.

    Вторая публикация — «Secure Design Patterns» (pdf). Это более свежая информация, отчет о работе, проделанной в Software Engineering Institute и спонсированной Министерством обороны США.

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

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

    Читайте, думайте, применяйте.

    Заключение


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

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

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

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

    P.S. Статья получилась большой. Я не стал делить ее на части, очень хотелось сохранить ее целостность. Надеюсь, было интересно, и я не слишком вас загрузил.

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

    habr
    Литература (микрообзор)
    1. Steve McConnel, “Rapid Development. Taming Wild Software Schedulers”, Microsoft Press 1996

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

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

    2. Steve McConnell, “Code Complete: A Practical Handbook of Software Construction”, Microsoft Press, Second Edition, 2004

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

    С точки зрения безопасности: плохо написанная программа не может быть безопасна.

    3. Eric J. Braud “Software Engineering: An Object-Oriented Perspective”, Wiley Computer Publishing, 2001

    В нашей стране эта книга вышла под названием «Технология разработки программного обеспечения».

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

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

    4. Len Bass, Paul Clements, Rick Kazman, “Software Architecture in Practice”, Addison-Wesley Professional, Second Edition, 2003

    Книга ведущих мировых специалистов в области архитектуры программного обеспечения.

    Описывается связь структуры (архитектуры) программного обеспечения и нефункциональных ее свойств: быстродействия, модифицируемости, безопасности и других.

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

    5. Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, Judith Safford “Documenting Software Architectures. Views and Beyond” Addison-Wesley Publishing 2008

    Еще одна книга ведущих мировых специалистов в области архитектуры программного обеспечения.

    Важной идеей книги является отсутствие одной, годной для описания всех свойств программного продукта «архитектуры». Полное описание архитектуры является объединением разных «точек зрения».

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

    6. Richard N. Tailor, Nenad Medvidovic, Eric M. Dashfy, “Software Architecture. Foundations, Theory, and Practice”, Wiley, 2010

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

    В отличие от двух предыдущих книг, является более академичной, фундаментальной.

    7. Matt Bishop “Computer security. Art and science”, Pearson education, 2003

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

    Хорошая фундаментальная книга.

    8. Jonh Viega, Gary McGraw “Building secure software. How to Avoid Security Problems the Right Way”, Addison-Wesley Publishing Company, 2005

    9. Gary McGraw “Software Security. Building Security in”, Addison-Wesley Publishing Company, 2006

    10. Greg Hoglund, Gary McGraw “Exploiting Software. How to Break Code”, Addison-Wesley Publishing Company, 2004

    Три книги, объединенные одним автором (Gary McGraw). С разных сторон описываются подходы к разработке и тестированию безопасности программного обеспечения.

    Здесь можно найти описание Touch Points — методики внедрения учета требований безопасности практически в любой процесс разработки ПО.

    Другая важная методика — Attack Patterns — может быть использована как при анализе проекта программного обеспечения, так и при разработке программы тестирования.

    11. Julia H. Allen, Sean Barnum, Robert J. Ellison, Gary McGraw, Nancy R. Mead, “Software Security Engineering. A Guide for Project Managers”, Addison-Wesley Publishing Company, 2008

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

    К сожалению, из описания не всегда очевидно, как ту или иную методику, метод можно использовать именно для проектирования или анализа безопасности.

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

    12. Mark S. Merkov, Lakshmikanth Raghavan, “Secure and Resilient Software Development”, Auerbach Publications, 2010

    Книга двух практиков. Оба они работают (по крайней мере, на момент написания книги) в PayPal Inc. Как вы догадываетесь, работы с безопасностью у них немало.

    Авторы, похоже, описывают методики, которые сами использовали и которые для них сработали. Книга охватывает весь цикл жизни программного обеспечения, начиная от проектирования до релиза.

    13. Michael Howard, David LeBlanc, “Writing Secure Code”, Microsoft Press, Second Edition, 2003

    14. Frank Swiderski, Window Snyder, “Threat Modeling”, Microsoft Press, 2004

    15. Michael Howard, Steve Lipner, “The Security Development LifeCycle”, Microsoft Press, 2006

    Знаменитые три книги издательства Microsoft. Думаю, много о них говорить не имеет смысла.

    Первая книга ориентирована (в большей степени) на программистов, вторая — на проектировщиков, третья — на менеджеров проекта.

    16. Michael Howard, David LeBlanc, Jonh Viega, “24 Deadly Sins of Software Security. Programming Flaws and How to Fix Them”, McGraw-Hill/Osborne, 2009

    Эта книга является развитием успешной публикации этих же авторов “19 Deadly Sins of Software Security. Programming Flaws and How to Fix Them”.

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

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

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

    17. Mark Down, John McDonald, Justin Schun, “The Art of Software Security Assessement. Identifying and Preventing Software Vulnerabilities”, Addison-Wesley, 2007

    Большая (1048 страниц) книга, практически энциклопедия, посвященная различным аспектам безопасности. Содержит описание проблем, связанных с отдельными языками; проблем взаимодействия с ОС; проблем использования современных веб технологий.

    Хорошая книга для начального знакомства с проблемами безопасности приложений.

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

    18. Karl E. Wiegers, “Peer Reviews in Software. A Practical Guide”, Addison-Wesley Publishing Company, 2010

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

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

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

    19. Paul C. Jorgensen “Software Testing. A Craftman's Approach”, Auerbach Publications, Third Edition, 2008

    Учебник по тестированию. Автор описывает разные подходы к созданию тестовых примеров, методы и методологии тестирования, метрики-показатели качества тестирования.

    В книге описывается тестирование «вообще», но многие идеи могут быть перенесены и в тестирование безопасности.

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

    20. Cem Kaner, “A Tutorial in Exploratory Testing”, 2008

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

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

    Документ легко найти в интернете.

    21. James A. Whittaker, “How to Break Software: A Practical Guide to Testing”, Addison-Wesley, 2002

    22. James A. Whittaker, “How to Break Software Security”, Addison-Wesley, 2003

    23. Mike Andrews, James A. Whittaker “How to Break Web Software: Functional and Security Testing of Web Applications and Web Services”, Addison-Wesley Professional, 2006

    24. James A. Whittaker, “Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design”, Addison-Wesley Professional, 2009

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

    Whittaker пропагандирует подход к исследовательскому тестированию, который несколько отличается от подхода Сема Канера.

    Методика, пропагандируемая автором, в чем-то напоминает подход Attack Patterns (метод анализа безопасности). Напоминает настолько, что кто-то даже скажет «совпадает», но, во многом, это и делает методику автора полезной при тестировании безопасности.

    25. Christoper Steel, Ramesh Nagappan, Ray Lai, “Core Security Patterns. Best Pracices and Strategies fo J2EE, Web Services, and Identity Management”, Prentice Hall, 2005

    Объемная книга (1088 страниц). Авторы охватывают практически все аспекты разработки безопасного программного обеспечения на платформе J2EE. Они описывают как возможности самой платформы, так и многие шаблоны безопасности.

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

    Поделиться публикацией
    Комментарии 22
      0
      Если это стоит X0000 долларов, то с большой вероятностью оно безопасное. Вот есть N долларов, то менее безопасное. Улавливаете мысль?
        0
        Оно безопасное, или справка есть, что безопасное?
          0
          Справки пока нет. А что важнее справка о том что безопасное или безопасное, если, например, исключительно для себя использовать?
            0
            Для себя, думаю, важнее, чтобы было безопасно. Вопрос, только, как об этом узнать?
        0
        Промазал
          +2
          Безопасность это хорошо и знать это хорошо, только вот не всем заказчикам объяснишь, что это нужно и платить за это редко кто хочет.
            0
            Вот с этим абсолютно согласен.

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

            А то, что это стоимость повышает, что это увеличивает время разработки…

            Скажу даже больше: не всем это надо Но, если надо…
              +1
              Пост конечно нужный, совсем не против, только за. Просто, почему-то это не очень котируется и это печально.
                +1
                Вы мне об этом рассказываете?

                А вообще, я тут читал курс и рассказывал, как показываю клиентам стоимость проекта.

                Я рисую прямоугольник, одна сторона которого — функциональность программы; другая сторона — ее качество. Безопасность относится к качеству. Стоимость разработки (и, конечно, ее время) будет в площади прямоугольника. А дальше, как скажет заказчик.
                  0
                  А помогает? Может тоже взять на вооружение…
                    +1
                    Это помогает договориться. А мне это помогает понять, что хочет заказчик.
            +4
            Много воды — интересны только ссылки в конце. Про ценные советы вроде «тестируйте» и «используйте библиотеки» я промолчу.
              0
              Тем не менее, вопросы задают. И цитата из начала статьи: «И, надеюсь, вы убедитесь, что в безопасном программировании нет ничего такого уж необычного.»

              На самом деле, для повышения безопасности надо делать очень-очень простые вещи. Надо только их делать.
                0
                Кстати, а Вы свои программы тестируете на безопасность? Если да, то как?
                  0
                  Не приходилось, по работе разрабатываю приложения для интранетов, своих проектов, которые бы этого требовали, тоже нет — поэтому тема мне интересна.
                  Из-за этого и выражаю некоторую разочарованность в статье, которая по-моему опоздала лет на 10-15, когда code review и тестирование было не очень распространено, особенно во всяких буллщит веб-проектах эпохи доткомов. Да, вокруг все еще много людей с галстуками вместо мозгов, кому такие советы не очевидны, есть конторы а-ля «РОСГОВНСОФТ» которые пишут свой php-фреймворк силами студентов за еду и бесплатный чай.
                  Если бы вы описали те-же методы secure design, со схемами и примерами из тех-же ссылок — была-бы интересная статья. А так похоже на курсовую, которая написана в ночь перед сдачей, уж не обессудьте.
                    0
                    Спасибо Вам большое за отзыв. Мне обратная связь с читателями очень полезна, вероятно, я действительно переупростил статью, и мне об этом даже мои друзья сказали.

                    Тем не менее, в статье написаны далеко не самые очевидные вещи.

                    Давайте возьмем, например, тестирование. Когда я в другом месте посоветовал делать его, мне сказали: «а Microsoft так не делает». Действительно, если вы посмотрите книгу по SDL (в моем микрообзоре она под номером 15), то там вы не найдете рекомендации тестировать безопасное поведение. Там есть fuzzing, там есть penetration testing. Но тестирования безопасного поведения — нет. И тогда пришлось разбираться, что мы получаем, внедряя эту практику, что теряем.

                    Так что, как минимум одна практика, которую Вы считаете очевидной, на деле оказывается спорной.

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

                0
                OpenSSL поддерживает концепцию Keystores?
                  0
                  Не очень понятно, что именно Вам нужно. OpenSSL поддерживает формат pkcs12.
                    0
                    Угу оно. Спасибо.
                  0
                  Простите за оффтоп.
                  Она: — А кем вы работаете?
                  Он: — Программистом систем безопасности данных.
                  Она: — Ой, это должно быть очень интересно! Все эти ваши асимметричные шифры, односторонние хэш-функции, таблицы подстановок, гаммирование, алгоритм Диффи-Хеллмана! Вы знаете, я в этом ничего не понимаю...
                    0
                    не смешно
                    0
                    Чтение статьи значительного объема представляет собой дилемму: тема сложная, интересно написанных публикаций по ней немного, а времени — дефицит. Поэтому необходимо тщательно подойти к выбору публикаций для прочтения. По теме безопасности все больше статей, написанных формальным языком, для специалистов, глубоко разбирающихся в вопросе.

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

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

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

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое