Secure by design что это

Перевод «secure by design» на русский

Secure by design, in software engineering, means that the software has been designed from the ground up to be secure.

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

Secure by Design: Cybersecurity Extensions to Project Management Maturity Models for Critical Infrastructure Projects

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

Such systems are «secure by design«.
Такие системы «безопасны по дизайну».

Contrary to common belief, public clouds are not highly secure by design, and so require additional protection.

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

ACEA’s guidelines are to be welcomed as an introduction to «secure by design» concepts for the automotive world.

Руководящие принципы АСЕА должны приветствоваться как введение в концепцию «безопасного проектирования» для автомобильного мира.

This latest report suggests that any Linux variation would not meet the standards of the secure by design brief from the ISILG.

Согласно последнему отчету, любой вариант на основе Linux не будет соответствовать стандартам безопасности по замыслу ISILG.

This underscores the increased focus among our clients to continue looking for security solutions that help them better manage risk and ensure their IT infrastructure is secure by design.

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

In addition, due to the fact that the same transaction is registered in multiple distributed database systems, the technology is secure by design.

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

Cybersecurity is at the core of our «secure by design» philosophy, and it’s embedded in all the Intelligent Power products and platforms we bring to market.

Кибербезопасность лежит в основе нашей философии «безопасность по определению», и она встроена во все продукты и платформы нашей линейки Intelligent Power.

But they are more secure by design.
It could be more secure by design.
Secure by design (unprivileged containers, resource restrictions and much more)
Безопасность (непривилегированные контейнеры, ограничения ресурсов и многое другое)

Developed in conjunction with the National Cyber Security Centre, manufacturers and retailers, the Secure by Design review specifies that security must be embedded in the design process rather than a bolt-on or an afterthought.

В обзоре Secure by Design, разработанном совместно с Национальным центром кибербезопасности, производителями и розничными торговцами, указано, что безопасность должна быть встроена в процесс проектирования, а не в болтовню или раздумья.

The government’s Secure by Design review, which was developed in collaboration with manufacturers, retailers and the National Cyber Security Centre, sets out plans to embed security in the design process rather than add them on as an afterthought.

Hosted systems can follow what Microsoft refers to as SD3+C: Secure by Design, Secure by Default, Secure in Deployment and Communications.

Следует отметить, что под громким маркетинговым названием скрывается формула, которую Microsoft записала в виде: SD3 + C (Security By Design, Security By Default, Security By Deployment и Communications).

Contrary to common belief, public clouds are not highly secure by design, and so require additional protection.

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

Secure by Design: BigFix software contributes to IBM’s security infrastructure that is secure by design — consolidating endpoint protection, systems lifecycle management, security configuration and vulnerability management.

Безопасностью, заложенной в архитектуре — Программное обеспечение BigFix способствует укреплению инфраструктуры безопасности IBM, построенной по принципу «secure-by-design», т.е. безопасной изначально, по своей сути — консолидируя средства защиты оконечных устройств, управления жизненным циклом систем, конфигурирования системы безопасности и управления уязвимостями.

Возможно неприемлемое содержание

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

Secure by Design: с чего начинается безопасность продукта

Можно ли при идеальном коде и защищённой инфраструктуре иметь серьёзные проблемы в безопасности продукта? Защитят ли нас полностью современные средства инфраструктурной защиты, анализа кода? А что, если нет? Давайте подумаем об этом на отвлечённых примерах из практики.

Привет, Хабр! Меня зовут Игорь Игнатьев, я директор департамента защиты приложений в VK. Сегодня расскажу о подходе к построению безопасных продуктов, и это будет моя первая статья из цикла про принципы Secure by Design.

Идеология Secure by Design в моём понимании — это интеграция свойств безопасности в будущий продукт наравне с функциональными требованиями. Первостепенно именно функциональные требования в продукте определяют его ключевые цели и идеи. Добавление свойств безопасности только в автоматизируемые части продукта (ИТ-системы) помогает создать безопасное приложение, но не продукт.

На конференциях и в статьях довольно часто говорят о подходе Secure by Design и о смещении Shift-Left в обеспечении безопасности продуктов компании, демонстрируя в расширенном или сжатом виде примерно такую схему:

Но в сложившейся практике рассуждать о безопасности продукта начинают с приложений, кода и его зависимостей, то есть фактически уже на этапах разработки и тестирования. Несомненно, устранение уязвимостей в коде до выхода приложения или сервиса в эксплуатацию является неотъемлемой частью Secure by Design, но безопасный код — это ещё не безопасный продукт. Более того, само по себе создание нового продукта или дополнительных функций в нём не всегда предполагает наличие исходного кода, доступного для анализа на безопасность. Это может быть и использование различных готовых «кирпичиков», модификация функциональности через настройки, использование Low-code-систем. Мы можем использовать BPM-системы без программирования, либо использовать шину данных, в которой новые интеграции реализуются через добавление заранее разработанных компонентов, как в Integration Bus от IBM.

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

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

Сегодня мы разберём первую часть, в которой необходимо участие безопасности, а именно этап Product Vision (PV) и проектирования бизнес-процессов в продукте (или клиентских путей). Этап PV фактически привносит основную ценность продукта и затрагивает ключевые процессы. Развитие составляющих продукта в дальнейшем начинается с детализации процессов, которые будут эту ценность реализовывать.

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

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

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

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

— Само начисление этих средств, исполняемое сотрудником поддержки.

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

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

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

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

Рассмотрим пример из другой области.

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

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

Списание бонусов в программе лояльности осуществляется при накоплении бонусов выше порога в 10 тысяч, и оплату ими товаров, сумма которых превышает 50 рублей (естественно, суммы тут могут быть любыми, это лишь пример).

Далее переходим к основному процессу покупок, куда встраивается бонусная программа:

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

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

Вероятно, вы уже нашли ключевую проблему, но для тех, кому лень:

Покупаем товары на 9 999 р, получаем условные 9 999 бонусов.
Возвращаем товар. И тут из-за дефекта связки в процессах мы попадаем на подпроцесс списания бонусов, который запускает проверку «Бонусов>10 000». И наша транзакция под эти условия не попадает.
У нас на руках остались возвращённые за товары деньги и 9 999 бонусов!
А дальше делаем, что захотим. Например, покупаем жвачку за 1 рубль, достигаем заветной цифры в 10 000 бонусов и накупаем на них товары.

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

Это была краткая демонстрация ошибки бизнес-логики, которую невозможно отловить автоматизированными средствами. Никакие SAST|DAST|API-fuzzing тут не помогут. Только руками и только человек, который понимает суть бизнес-процесса и способен идентифицировать риски безопасности в нём, может привнести необходимые свойства в архитектуру и сделать продукт тем самым “Secure by Design”.

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

Часть 1. Погружение в процесс и PV

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

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

3. Определить состав информации. Какие данные обрабатывает процесс, обеспечен ли он вообще этими данными?

4. Определить границы бизнес-процесса. Описан ли процесс полностью, либо где-то в нём есть мёртвые и недостижимые ветки или потерянные выходы? Чем больше процесс, тем больше логических ошибок в нём может содержаться.

Часть 2. Работа с задачами

Здесь мы идём по каждому действию в процессе:

1. Проверить условия выполнения действия. Каждое действие требует для соблюдения определённых условий, например, для возврата товара в магазине нужно написать заявление. То есть операция по возврату не может начаться до завершения предыдущего процесса.

2. Проверить состав и полномочия участников. Кто выполняет действие, есть ли у него право на его выполнение? Нельзя возложить на сотрудника проверку, например, актуальности банковской карты, потому что это работа процессинга банка. То же касается и полномочий, когда человек с определённой ролью не может быть участником каких-либо операций.

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

Часть 3. Работа со связями в процессе

1. Проверка достаточности и избыточности связей. Базовая гигиеническая проверка (особенно актуальная для больших процессов) связана с контролем брошенных операций и дублирующих взаимодействий.

2. Проверка цепочек и циклов. Второе действие над связями, предполагающее оценку процесса на наличие замкнутых контуров и зацикливания.

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

Часть 4. Работа с условиями и развилками

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

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

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

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

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

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

Блог компании VK
Информационная безопасность

Secure by Design

Secure by Design в кибербезопасности — это подход, который включает меры по обеспечению безопасности программного обеспечения с самого начала его разработки. Это означает, что инженеры должны сразу создавать своё ПО таким образом, чтобы снизить вероятность появления уязвимостей, которые смогут повлиять информационную безопасность продукта.

Ваш провайдер знает о вас больше, чем ваша девушка? Присоединяйтесь и узнайте, как это остановить!

6 сентября, 2023

Бывший член «Культа Мёртвой Коровы» вступил в ряды CISA

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

Безопасный дизайн — Secure by design

Безопасно по дизайну (SBD) в программной инженерии означает, что программное обеспечение спроектировано с самого начала как безопасный. При таком подходе сначала рассматриваются альтернативные тактики и шаблоны безопасности; среди них лучшие отбираются и воплощаются в жизнь архитектурным дизайном, а затем используются в качестве руководящих принципов для разработчиков. Также рекомендуется использовать шаблоны проектирования, которые положительно влияют на безопасность, даже если эти шаблоны проектирования изначально не были разработаны с учетом требований безопасности. Secure by Design все чаще становится основным подходом к разработке для обеспечения безопасности и конфиденциальности программных систем. При таком подходе безопасность встроена в систему с нуля и начинается с надежной архитектуры. Решения по проектированию архитектуры безопасности часто основываются на хорошо известных тактиках безопасности и шаблонах, определяемых как методы многократного использования для решения конкретных задач качества. Тактики / шаблоны безопасности предоставляют решения для обеспечения необходимой аутентификации, авторизации, конфиденциальности, целостности данных, конфиденциальности, подотчетности, доступности, безопасности и неотказуемости, даже когда система находится в атака. Чтобы обеспечить безопасность программной системы, важно не только разработать надежную архитектуру безопасности (предназначенную), но также необходимо сохранить (реализованную) архитектуру в процессе эволюции программного обеспечения. Вредоносные действия считаются само собой разумеющимся, и принимаются меры для минимизации воздействия в ожидании уязвимостей безопасности, когда уязвимость безопасности обнаруживается или при недопустимом вводе пользователя. Тесно связана практика использования «хорошего» дизайна программного обеспечения, такого как доменно-ориентированный или облачный, как способ повышения безопасности за счет снижения риска ошибок, связанных с открытием уязвимостей — даже несмотря на то, что используемые принципы проектирования не были изначально задуманы в целях безопасности.

Как правило, хорошо работающие проекты не полагаются на секретность. Часто секретность снижает количество злоумышленников за счет демотивации подмножества угроз. Логика состоит в том, что если для злоумышленника усложняется, то злоумышленник прилагает больше усилий для компрометации цели. Хотя этот метод подразумевает снижение неотъемлемых рисков, практически бесконечный набор действующих лиц и методов, применяемых с течением времени, приведет к сбою большинства методов секретности. Хотя это и не является обязательным, надлежащая безопасность обычно означает, что каждому разрешено знать и понимать дизайн, потому что он безопасен. Это имеет то преимущество, что многие люди смотрят на компьютерный код, что увеличивает вероятность того, что какие-либо недостатки будут обнаружены раньше (см. закон Линуса ). Злоумышленники также могут получить код, который упрощает им поиск уязвимостей.

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

1 Обеспечение безопасности на практике
2 Архитектура сервера / клиента
3 Ссылки
4 См. Также
5 Внешние ссылки

Безопасность на практике

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

Два примера небезопасной конструкции допускают переполнение буфера и уязвимости строки формата. Следующая программа на C демонстрирует эти недостатки:

#include int main ()

Поскольку получает функцию в стандартной библиотеке C не прекращает запись байтов в буфер , пока не прочитает символ новой строки или EOF, ввод более 99 символов в командной строке означает переполнение буфера. Выделение 100 символов для buffer с предположением, что почти любое имя пользователя не длиннее 99 символов, не мешает пользователю набрать более 99 символов. Это может привести к выполнению произвольного машинного кода.

Второй недостаток заключается в том, что программа пытается распечатать свой ввод, передавая его непосредственно в функцию printf . Эта функция выводит свой первый аргумент, последовательно заменяя спецификации преобразования (такие как «% s», «% d» и т. Д.) Другими аргументами из своего стека вызовов . по мере необходимости. Таким образом, если злонамеренный пользователь ввел «% d» вместо своего имени, программа попытается распечатать несуществующее целочисленное значение и неопределенное поведение произошло бы.

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

http://www.example.net/cgi-bin/article.sh?name=dogfood.html

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

http: // www.example.net / cgi-bin / article.sh? name =.. /.. /.. /.. /.. / etc / passwd

В зависимости от сценария это может открывать / etc / passwd, который в Unix-подобных системах содержит (среди прочего) идентификаторы пользователей, их имена входа, home каталог пути и оболочки. (См. SQL-инъекция для аналогичной атаки.)

Архитектуры сервер / клиент

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

Часто самый простой способ взломать систему защиты клиент / сервер — это не обращаться к механизмам безопасности, а вместо этого обходить их. Атака «человек посередине» — простой пример этого, потому что вы можете использовать ее для сбора деталей, чтобы выдать себя за пользователя. Вот почему важно учитывать шифрование, хеширование и другие механизмы безопасности в вашем проекте, чтобы гарантировать, что информация, полученная от потенциального злоумышленника, не позволит получить доступ.

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

Ссылки

См. Также

Компьютерная безопасность
Стандарты кибербезопасности
Повышение уровня защиты
Несколько независимых уровней безопасности
Безопасность по умолчанию
Безопасность через неизвестность
Software Security Assurance

Внешние ссылки

HOWTO по безопасному программированию для Linux и Unix
Часто задаваемые вопросы по безопасному программированию UNIX
10 лучших практик безопасного программирования
Безопасность благодаря принципам проектирования