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 рублей (естественно, суммы тут могут быть любыми, это лишь пример).

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

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

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

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

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

Конструктивная информационная безопасность — Security by Design

Альтернативный подход — разработка конструктивно безопасных систем (англ. Secure by Design). Его суть заключается в проектировании киберсистем, в которых меры безопасности интегрированы в архитектуру и программный код и являются его частью. В этом случае аспекты безопасности принимаются во внимание начиная с самых ранних стадий разработки — требования безопасности приравниваются к функциональным требованиям и влияют на выбор архитектуры решения и аппаратной базы.

Этот подход применяется в прикладных сферах, традиционно относящихся к критическим, — например, в авиастроении концепция архитектуры IMA (Integrated Modular Avionics) полностью соответствует принципам Security by Design. Тем не менее широкого распространения подход пока не получил, на что есть несколько причин:

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

Таким образом, необходима простая и экономически эффективная методология, которая позволит воплощать безопасность не как результат персонального искусства отдельных разработчиков, а в итоге спланированной деятельности. Кибериммунный подход к разработке от «Лаборатории Касперского» претендует на решение этой задачи.

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

Кибериммунный подход — это эволюционное развитие технологий обеспечения безопасности, в основе которого теоретическая база и мировые практики построения безопасных систем в области промышленности, транспорта, управления. Подход объединяет экономически эффективную методологию разработки киберсистем с архитектурными требованиями к ним, что позволяет применять его в различных сферах.
Целью кибериммунного подхода является создание кибериммунной системы — киберсистемы, декларированные активы которой защищены от нежелательных событий при любых условиях, даже под атакой, при условии заданных ограничений.
Кибериммунный подход состоит из двух частей, нацеленных на методическое обеспечение подхода Security by Design:

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

Первую из этих составляющих кибериммунного подхода подробно рассмотрим в следующей части — «Процессные требования: цели безопасности и моделирование угроз».

Поделиться

Альтернативный подход — разработка конструктивно безопасных систем (англ. Secure by Design). Его суть заключается в проектировании киберсистем, в которых меры безопасности интегрированы в архитектуру и программный код и являются его частью. В этом случае аспекты безопасности принимаются во внимание начиная с самых ранних стадий разработки — требования безопасности приравниваются к функциональным требованиям и влияют на выбор архитектуры решения и аппаратной базы.

Этот подход применяется в прикладных сферах, традиционно относящихся к критическим, — например, в авиастроении концепция архитектуры IMA (Integrated Modular Avionics) полностью соответствует принципам Security by Design. Тем не менее широкого распространения подход пока не получил, на что есть несколько причин:

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

Таким образом, необходима простая и экономически эффективная методология, которая позволит воплощать безопасность не как результат персонального искусства отдельных разработчиков, а в итоге спланированной деятельности. Кибериммунный подход к разработке от «Лаборатории Касперского» претендует на решение этой задачи.

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

Кибериммунный подход — это эволюционное развитие технологий обеспечения безопасности, в основе которого теоретическая база и мировые практики построения безопасных систем в области промышленности, транспорта, управления. Подход объединяет экономически эффективную методологию разработки киберсистем с архитектурными требованиями к ним, что позволяет применять его в различных сферах.
Целью кибериммунного подхода является создание кибериммунной системы — киберсистемы, декларированные активы которой защищены от нежелательных событий при любых условиях, даже под атакой, при условии заданных ограничений.
Кибериммунный подход состоит из двух частей, нацеленных на методическое обеспечение подхода Security by Design:

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

Первую из этих составляющих кибериммунного подхода подробно рассмотрим в следующей части — «Процессные требования: цели безопасности и моделирование угроз».

Безопасный дизайн — 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 лучших практик безопасного программирования
• Безопасность благодаря принципам проектирования

Фишинг, вишинг, Security by Design

Дмитрий Гадарь, директор департамента информационной безопасности банка Тинькофф, обозначил несколько трендов в современной ИБ, выступая на круглом столе «Информационная безопасность: проблемы и решения», который прошел в рамках XIX Международного банковского форума «БАНКИ РОССИИ – XXI ВЕК».

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

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

Дмитрий Гадарь рассказал ещё об одном тренде: «Мы заметили, что в даркнете и в различных телеграм-каналах была информация о том, что готовы заплатить сотрудникам финансовых организаций деньги, чтобы они предоставили удалённый доступ к банковским системам. Мне неизвестны такие случаи, но вектор кажется достаточно правдоподобным. В связи с чем администраторам нужно дополнительно контролировать сотрудников в этом направлении».

По словам эксперта, больше стало тематического фишинга по специальной военной операции.

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

BIS Journal — главный медиапартнёр форума «БАНКИ РОССИИ – XXI ВЕК».