Важность безопасности кода: советы от Юрия Шабалина

Разработчики игр и ПО

Введение

Продукт разработки программного обеспечения (далее — ПО) для внутренних нужд или для внешнего заказчика гарантированно уязвим в определенной мере. Причины этого очевидны. Существуют проблемы языка разработки (библиотек, среды выполнения runtime): например, в приложениях, созданных на языке Java, регулярно находят уязвимости. Уязвимы сами платформы функционирования и разработки. Не идеальны внешние подключаемые модули и дизайн программного обеспечения. Зачастую плохо организован сам процесс разработки.

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

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

Сказываются и давление со стороны бизнеса (диктуются сроки и программные доработки — feature requests), и отсутствие понимающей позиции у коллег-безопасников, сетевиков, инфраструктурщиков (один сервер под множество баз данных разного уровня доверия) — эти факторы приводят к увеличению рисков информационной безопасности ПО. Например, нередка ситуация: программная доработка требует организации нового сетевого общения между серверными компонентами, но согласование нового сервиса требует такого количества времени, которое в соблюдение даты закрытия запроса на доработку (feature request) не вписывается; разработчик ускоренно «ковыряет дырку» в знакомом месте, в обход политики ИБ, возможно, даже с временным согласованием безопасника при условии, что потом все будет сделано как следует, но почти наверняка это «потом» не наступает, и в архитектуре остается уязвимость.

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

Когда нужно задумываться о безопасности кода

— Есть ли какие-то стадии жизненного цикла продукта, на которых такими вопросами и пентестами даже не стоит озадачиваться? Или типы продуктов, в которых это не принципиально?

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

Есть такая замечательная методология, фреймворк Building Security In Maturity Model (BSIMM). Это анализ уровня зрелости. Лозунг этой методологии сейчас — shift everywhere. В отличие от shift left (сдвига влево, к самым ранним стадиям разработки), новая парадигма предполагает анализ безопасности везде, где он принесёт наибольшую пользу.

Будьте честны и признавайте, если не справляетесь с обязанностями

В какой-то момент своей карьеры вы можете оказаться на месте, которое вам не подходит. Несовместимость — это не недостаток характера. Это проблема, которую нельзя игнорировать. У неё может быть несколько решений: вы можете измениться или ваши задачи могут стать другими. Суть в том, чтобы прислушаться к себе, понять происходящее и выбраться из нездоровой ситуации.

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

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

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

Средства анализа кода

Решения по анализу кода осуществляют поиск известных уязвимостей в разработанном коде ПО. Проверка выполняется как для исходного кода — статический анализ, или SAST (Static Application Security Testing), — так и для исполняемого — динамический анализ, или DAST (Dynamic Application Security Testing). Динамический анализ фактически является первым этапом тестирования на проникновение (penetration test) для приложения.

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

Подробный обзор продуктов класса анализаторов кода можно посмотреть в статье Екатерины Бойцовой: https://www.anti-malware.ru/reviews/Code_analyzers_market_overview_Russia_and_world

Coding standart

Тестирование в XP

Распорядок программирования:

  • Пишем тест.
  • Быстро добиваемся, чтобы он заработал.
  • Рефакторим.

ХП-тесты не заменяют других видов тестов (usability, производительности и пр.)
и не отменяют необходимость в специально выделенной деятельности по собственно
тестированию, отделённой от процесса программирования.

ХП-тесты должны работать быстро. ХП-тесты должны быть независимыми. В таком
режиме мы все ситуации, конечно же, не отловим, но компромисс здесь
сознательный.

Выглядеть тест будет примерно так, при этом написание теста Бек рекомендует
начинать с конца, с assert-ов.

testCompleteTransaction() { 
    Server writer= Server(defaultPort(), "abc"); 
    Socket reader= Socket("localhost", defaultPort()); 
    Buffer reply= reader.contents(); 
    assertTrue(reader.isClosed()); 
    assertEquals("abc", reply.contents()); 
}

Окружение, реализующее все эти assertXXX, рисующее зелёные полоски,
когда тесты прошли и красные, когда нет, называется xUnit, например,
для Явы будет jUnit, для C — cUnit и пр

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

По ходу дела отметим вот что. Раз уж у нас появилась куча тестов, про которые
мы думаем, что знаем, что они работают, то можно попытаться проделать
следующую вещь. Возьмём исходники и покорёжим их. Если тесты не перестали
работать, то это плохие тесты. Средство, реализующее этот процесс
для Явы называется jester, а для Питона —
pester.

Footnotes

… быстро

«А кто не все, того накажем!»


проект

Оптимизирующий компилятор, скажем.


увольнять

На меня большое впечатление произвело полное отсутствие
в текстах про ХП глагола to fire. Гуманисты писали!


работе”

Ландау, возможно, и пожалел, но он на работе редко писал
ЗАРПЛАТУ для Крайслера.

… В

Для трамвайного чтения, как сказал бы В.В.Самофалов.


pester

http://www.jesterinfo.co.uk/

A.V.Konovalov
2003-03-16

Кто должен быть лидером безопасной разработки

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

Что такое план аварийного восстановления

План аварийного восстановления — документ, который содержит шаги по устранению последствий аварии и восстановлению данных; список ответственных сотрудников, их роли и обязанности; последовательность действий по защите и восстановлению IT-инфраструктуры.

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

  • восстановить IT-инфраструктуру бизнеса после аварии в приемлемые сроки;
  • обеспечить работу критически важных функций IT-инфраструктуры во время простоя основного ЦОД;
  • сохранить данные компании в нужном объеме.

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

Чтобы обеспечить катастрофоустойчивость бизнеса и непрерывность его работы, компания может дублировать IT-сервисы в собственный дата-центр или использовать облачные сервисы, когда Disaster Recovery предоставляется провайдером как услуга.

Книжки на русском

Обложка Название книги Комментарий (ToDo)
Кен Ауэр, Рой Миллер. Экстремальное программирование – постановка процесса с первых шагов и до победного конца.DjVu версия c оглавлением, содержанием, поиском
Фредерик Брукс. Мифический человекомесяц или как создаются программные системы.DjVu версия c оглавлением, содержанием, поиском, PDF версия
Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приёмы объектно-ориентированного программирования – паттерны проектирования.DjVu версия c оглавлением, содержанием, поиском
Мартин Фаулер. Рефакторинг – улучшение существующего кода.DJVU версия Создать интерактивное оглавление, разметить ссылки в содержании
Кент Бек. Экстремальное программирование – разработка через тестирование.DJVU версия Создать интерактивное оглавление, разметить ссылки в содержании
Дуг ДеКарло. Экстремальное управление проектамиDJVU версия Создать интерактивное оглавление, разметить ссылки в содержании
Кент Бек, Мартин Фаулер. Экстремальное программирование: планирование.PDF версия найти DjVu версию
Кент Бек. Экстремальное программирование.RTF версия найти DjVu версию
Скотт Амблер. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки.DJVU версия обложка, OCR, и т.д.
Том ДеМарко “Deadline. Роман об управлении проектами”DOC версия найти DjVu версию
Стив Макконнелл. Совершенный код.DJVU версия
Стив Макконнелл. Сколько стоит программный проект.DJVU версия с поиском Дополнить интерактивное оглавление (сейчас есть только общий план + первые главы)
Йордон Э. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. (2002)DjVu версия Найти нормальную отсканенную версию.

Pair programming

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

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

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

Налицо, по-моему, попытка выдержать текучесть кадров. То, что писать
интеллектуально сложные куски или под временным прессингом искать
плоховоспроизводимую ошибку лучше вдвоём — все и так знают, об этом и
в книжках лет 30 как пишется, но ЗАЧЕМ вдвоем рисовать экранные формы
мне совершенно непонятно.

Стандарты и рекомендации

В вопросах организации и процессов безопасной разработки существует много стандартов и рекомендаций. 1 июня 2017 года введен в действие для добровольного применения ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения. Общие требования». Стандарт описывает комплекс мер, реализуемый в процессах функционирования и сопровождения ПО, формирования и поддержания среды обеспечения оперативного устранения выявленных пользователями ошибок ПО, направленный на снижение рисков появления уязвимостей. ГОСТ содержит перечень действий, которые рекомендуется осуществить на различных этапах жизненного цикла ПО, и является российским аналогом концепции SDL (Security Development Lifecycle).

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

  • защиты web-приложений WAF (Web Application Firewall),
  • защиты DNS,
  • защиты БД DBF (Database Firewall),
  • разграничения и фильтрации сетевых взаимодействий уровня NGFW, UTM, IPS-решений,
  • антивирусной защиты.

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

Write tests first

С одной стороны,
воскресным проповедям о пользе тестирования лет минимум 30. С другой
стороны, злые языки утверждают, что упор на тесты в ХП — следствие
слабой статической типизации Smalltalk-а, из каковой культуры ХП и
выросло. С третьей — совершенно непонятно, почему воспеваются тесты и
полностью игнорируются инварианты, средство не менее мощное. Рассказ
о программисте, запускавшем тесты на нервной почве перед выступлением,
умиляет особенно. А если б он ногти грыз перед выступлением, доказывало
бы это пользу грызения ногтей в программном проекте?
Более подробно о тестировании в ХП см. в разделе .

Ссылки

  • http://www.maxkir.com/

  • http://all-ebooks.com

  • http://wiki.agiledev.ru/doku.php?id=&idx=tdd

  • http://wiki.agiledev.ru/doku.php?id=books

  • буч анализ и проектирование цена

  • http://www.pdc.ru/warez/edonkey2k.html

  • http://www.menloinstitute.com/freestuff/whitepapers/pairedprogramming_qanda.htm

  • http://weblogs.asp.net/tags/.Net+Quotations/default.aspx?PageIndex=6

  • http://www.programmerworld.net/dotnet/books.htm

  • http://www.itebookhome.com/csharp.asp

  • http://www.itebookhome.com/ExtremeProgramming.asp

Extreme Programming Applied: Playing To Win

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software

Test-driven Development by Example

Doug DeCarlo. eXtreme Project Management

Planning Extreme Programming

Extreme Programming Explained: Embrace Change

Agile Modeling: Effective Practices for Extreme Programming

Steve McConnell. Code Complete. Second Edition

Steve McConnell. Software Estimation: Demystifying the Black Art

Edward Yourdon. Death March

40-hour week

Мотивировка
понятна: усталые разработчики переругаются, да и процент ошибок вырастет.
Лозунг проникнут социальным гуманизмом, действительно, “никто ещё не пожалел
на смертном одре, что слишком мало времени проводил на
работе”. С другой стороны, на смутные подозрения наводит,
что оптимум продуктивности среднего программиста вдруг совпал с указаниями
КЗоТа. В
книжке Йордана Путь камикадзе. Как разработчику программного обеспечения
выжить в безнадежном проекте
утверждается, что при адекватной мотивации 60
часов в неделю можно работать неограниченно долго. Напомним также знаменитые
майки разработчиков Macintosh-а: “Working 100 hours per week and love
it”. Так что, во многом рецепт ХП — отражение ситуации времён бума.

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

Как найти хорошего лида безопасной разработки

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

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

Но кто-то должен весь этот процесс координировать. Кто-то, кто скажет: «Вася, ты новости постоянно читаешь. Скидывай мне самые интересные двумя предложениями. Дима, ты в CTF постоянно участвуешь. Их же выкладывают в паблик иногда. Скидывай мне то, что тебе понравится, какие там интересные кейсы были. Мы их будем включать».

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

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

— Наверное, последний вопрос, который хотел бы задать. Он неконкретный совсем. Возможно, мы о чём-то забыли поговорить. Может быть, упустили какие-то важные темы.

Contents

  • Чем мы займёмся и кому это надо

Чем мы займёмся и кому это надо

По-видимому, если принимать всерьёз аргументацию пропагандистов
XP, XP вызовет единственную реакцию — тотального неприятия. И действительно,
здравые инженерные и организационные методики зачем-то подкрепляются
ничего не выдерживающими психологическими, антропологическими и ещё
бог весть какими рассуждениями. Будет, однако, очень жаль, если это
случится — методики-то действительно здравые.

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

Литература

  1. Бек Экстремальное программирование, Питер, 2002, 224 с.
  2. Beck Test-Driven Development By Example Draft July 14,
    2002 1:31 pm, 239 p.
  3. Кент Бек Экстремальное программирование // Открытые системы,
    #01-02/2000
    http://www.osp.ru/os/2000/01-02/059.htm
  4. http://www.wiki.org/cgi/wiki?ExtremeProgramming

Цели XP

В основе XP лежит стремление уменьшить риски при разработке ПО. Риски
учитываются самые разные:

  • Невыполнение сроков поставки ПО.
  • Снижение качества ниже приемлимого уровня.
  • Внезапный уход из команды трёх ведущих разработчиков.

Область применения XP

Разработка заказного ПО командами программистов по 10-15 человек
в течении года-двух.

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

Необходимо также осознавать, что конкретика, о которой пишет Бек, относится
к периоду бума конца 90-х, и вряд ли повторится при нашей жизни.
К примеру, стандартный механизм повышения программистом своей зарплаты в то
время — смена работы; при том, что в “традиционных” инженерных
специальностях найти работу не просто, и на первый план выходит карьерный
рост “на месте”. Ясно, как ситуация бума повлияла на лозунги Pair
programming и Collective code ownership.

Процесс

Процесс разработки организован итеративно, причём не просто итеративно, а со
вложенными итерациями. Каждая итерация устроена так:

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

Остерегайтесь проклятия знания

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

Если не остерегаться проклятия знания, оно может запутать все формы коммуникации, включая код. Чем более специализирована ваша работа, тем выше риск, что вы будете использовать способы, непонятные непосвящённым.

Боритесь с проклятием знания. Работайте над пониманием своей аудитории. Попробуйте представить, каково это — узнать впервые о том, о чём вы говорите.

Практика внедрения безопасной среды

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

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

Инициатива включает в себя различные мероприятия, которые знакомят участников компании с тем, что в принципе есть такое понятие, как безопасность, что оно важно

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

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

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

Подборку составить довольно просто, поскольку информации очень много. Безопасник, уделяя в день по 10–15 минут, спокойно может составлять такие дайджесты и рассылать с небольшой преамбулой еженедельно. Это реально работает, хоть и не сразу. Но через пару-тройку недель народ начинает включаться. Условно, у разработчика, который пишет на Java, новость: «Обнаружена критическая уязвимость в Java-библиотеке, благодаря которой удалось получить доступ к 50% продуктов, которые её используют». Он её прочитал и подумал: «Интересно. Пойду посмотрю, есть ли у меня в проекте или нет». Такие вещи цепляют.

Хорошо работают внутренние курсы. Когда приходит новый сотрудник из целевого подразделения, то есть тестировщик, аналитик, безопасник, разработчик, ему назначается лёгкий интерактивный курс с базовыми знаниями. Его основная цель — показать, что в компании есть безопасность, рассказать об основных принципах конкретного направления. И в завершение: «Коллеги, если у вас возникнут вопросы по безопасности, у нас есть специальный ящик, специальный чат-канал в мессенджере. Пожалуйста, обращайтесь». Такое первое знакомство с безопасностью в компании.

Кадр: сериал «Мистер Робот»

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

Дальше больше. На что только хватит фантазии. Мы проводили CTF — Capture The Flag. Это формат, когда у тебя есть некоторый заранее уязвимый сервис. Допустим, веб-приложение. В нём есть ряд уязвимостей, за эксплуатацию каждой из которых даётся флаг (несколько очков). Выясняют, кто нашёл больше флагов, кто самый главный хакер в компании. Можно устроить церемонию награждения, присвоить почётные звания, подарки вручить. Организовать потом вебинар с разбором заданий.

И эта активность хорошо помогает искать security champion. Она подсвечивает, кто из разработки, из тестирования либо показал наилучшие результаты, либо проявил наибольшую активность. Это и есть потенциальные чемпионы, которые наверняка проявят себя и в других активностях. Главное — постоянно поддерживать тему, подбрасывать дровишек в этот костёр.

Что почитать о безопасной разработке программного обеспечения

— Это ещё не финальный аккорд. Я понял, о чём я забыл спросить. Что порекомендуешь почитать, посмотреть по теме? Может быть, подписаться на кого-то? Какие-то курсы, может быть?

— Конечно же, подписывайтесь на мой канал в Telegram Mobile AppSec World. Он про безопасность мобильных приложений, но сопутствующие материалы я тоже публикую. Читайте и другие Telegram-каналы по безопасности, которых немало. Они разного качества и разной тематики, разной направленности, нужно выбирать.

Рекомендую посмотреть фреймворки BSIMM (Building Security In Maturity Model), и OpenSAMM от OWASP, посвящённые безопасной разработке.

Рекомендую также по возможности участвовать в конференциях по безопасности — OFFZONE, Positive Hack Days, ZeroNights, а также в локальных мероприятиях, митапах от OWASP, Mail.ru, «Яндекса» и так далее. После ивентов все выкладывают записи докладов и презентаций. Так что можно смотреть что интересует в удобное для вас время.

Как сделать разработку безопасной

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

— Всё зависит от состояния компании, от того, есть ли у неё уже готовые продукты, от того, есть ли у неё отдел безопасности и как он участвует в разработке. В общем, я бы порекомендовал сделать так: взять тот же самый BSIMM или OWASP SAMM — это фреймворки, рассказывающие в принципе о том, что делается в мире для безопасности приложений. В них есть чек-листы, опросники, которые стоит использовать, чтобы понять, на каком уровне находится сейчас компания, над чем нужно работать. И заняться устранением пробелов, создав план действий.

Books in English

Cover Title Comments
Weinberg G.M. Psychology of computer programming.DJVU version Создать интерактивное оглавление, разместить ссылки на страницах
Andy Hunt, Dave Thomas – Pragmatic Unit Testing With CSharpPDF version, DJVU version
Doug Wallace, Isobel Raggett, Joel Aufgang – Extreme Programming for Web ProjectsCHM version
Jeffries, Anderson, Hendrickson – Extreme Programming InstalledCHM version
Jesse Liberty, Brian MacDonald – Learning C Sharp 2005CHM version
Kent Beck – Extreme Programming Explained – Embrace Change (1999)CHM version
Kent Beck – Test-Driven Development By ExampleCHM version
Kent Beck, Cynthia Andres – Extreme Programming Explained – Embrace Change (2004)CHM version
Kent Beck, Martin Fowler – Planning Extreme ProgrammingCHM version
Lisa Crispin, Tip House – Testing Extreme ProgrammingCHM version
Matt Stephens, Doug Rosenberg – Extreme Programming Refactored – The Case Against XPCHM version
Michele Marchesi, Giancarlo Succi, Don Wells, Laurie Williams – Extreme Programming PerspectivesCHM version
Michele Marchesi, Giancarlo Succi – Extreme Programming Examined – A Reasoned Collection of the Papers Presented at XP2000DJVU version, separate articles in PDF
Neil Roodyn – eXtreme .NET – Introducing eXtreme Programming Techniques to .NET DevelopersCHM version
Pete McBreen – Questioning Extreme ProgrammingCHM version
Ron Jeffries – Extreme Programming Adventures in CSharpCHM version
Stewart Baird – Teach Yourself Extreme Programming In 24 HoursCHM version
William C. Wake. Extreme Programming ExploredDJVU version, PDF version
Robert C. Martin. Clean Code. A Handbook of Agile Software CraftsmanshipPDF version
  • Extreme Programming in Practice (Paperback) by James W. Newkirk, Robert C. Martin
  • Agile Software Development: Principles, Patterns, and Practices by Robert C. Martin
  • Implementation Patterns, Kent Beck, Addison-Wesley, 2007.
  • Literate Programming, Donald E. Knuth, Center for the Study of Language and Information, Leland Stanford Junior University, 1992.

Остерегайтесь привязки

Постоянно появляются новые продукты, которые обещают произвести революцию в разработке программного обеспечения. Средства автоматизации разработки программ (CASE), готовые к использованию технологии (COTS), продукты планирования ресурсов предприятия, такие как Peoplesoft и SAP, и да, даже Ruby. Они заявляют об удивительном сокращении затрат и времени, если вы поверите в их целостную философию.

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

Сосредоточьтесь на основах

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

  1. Работа в команде — отличные команды создают отличное ПО. Не воспринимайте командную работу как должное.
  2. Доверие — команды работают на доверии. Будьте надёжным человеком, с которым сами бы хотели работать.
  3. Коммуникация — общайтесь честно и проактивно. Избегайте проклятия знания.
  4. Поиск консенсуса — найдите время, чтобы собрать всю команду. Пусть обсуждение и несогласие приведут вас к лучшему решению.
  5. Автоматическое тестирование — хорошо протестированный код позволяет вашей команде двигаться быстро и уверенно.
  6. Чистый, понятный и удобный для навигации код — думайте о следующем разработчике, который будет работать с вашим кодом, как о заказчике. Пишите код, который не будет вызывать проблем с чтением, обслуживанием и обновлением.

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

— Я правильно понимаю, что в подавляющем большинстве разработчики об этих вещах не задумываются или просто в них не разбираются, поэтому не знают, что об этом стоит думать?

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

Именно поэтому важно учитывать аспекты и начинать заниматься безопасностью ещё на этапе архитектуры. Предусмотреть взаимную аутентификацию сервисов или что-то подобное

Collective code ownership

Связь с текучестью кадров тоже понятна, но есть и более тонкие причины.
Известна, к примеру, практика “code review”, когда люди садятся в кружок
и исходник читают, задавая вопросы. Проблема тут вот в чём: единоличный
автор этого куска подсознательно стремиться защитить своё детище от злобных
ругателей (“Пусть корявое, но моё”), а значит, другие участники разбора
стремятся не обидеть хорошего человека и, значит, критикуют неглубоко.
Можно сколько угодно самозомбироваться на тему неотожествления со своим
исходником, но вот ХП предлагает совсем другой метод, не моральный, а
инженерный.

Planning game

  • затраты,
  • время,
  • качество,
  • объем работ.
  1. Заказчик определяет “набор пожеланий” к существующей системе
    (в диапазоне от критических ошибок до желательных новых возможностей)
    и заносит их на карточки, каждая возможность — на свою.
  2. Разработчики расставляют на карточках временные затраты, измеряемые
    в “идеальном времени разработки”. Идеальное время связано с календарным
    через зависящий от продуктивности конкретного разработчика коэффицент,
    например, . Пропагандируется, что если коэффицент слишком мал — это
    плохо, это значит, что Вы другим мало помогаете.
  3. На основе временных ресурсов текущей итерации заказчик выделяет
    карточки для реализации в текущей итерации.
  4. Карточки, не попавшие в текущую итерацию, не выбрасываются — они
    будут участвовать в следующих.

Сколько зарабатывают специалисты по безопасности

— Я смотрел как-то по вакансиям, общался со знакомыми безопасниками. Сложилось впечатление, что у безопасников зарплаты поменьше, чем у программистов. Если есть серьёзный спрос, есть такая нехватка, то почему они не растут, не дорастают до зарплат программистов? Во-вторых, насколько я понял, даже порог входа в безопасность значительно выше, чем в программирование. Чтобы получить первую работу, надо гораздо больше времени потратить, чтобы стать безопасником, чем разработчиком. Почему так сложилось? Может быть, это не так?

— Я бы поспорил. Внутри безопасности есть много всего, на чём можно специализироваться. Есть безопасность Kubernetes, есть тестирование на проникновение, есть безопасность приложений, реагирование на инциденты, разработка.

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

Rate article