Концепты безопасного ПО
Last updated
Last updated
Несколько лет назад безопасность была про то как удержать плохих парней в стороне от вашей сети. Сетевая безопасность широко руководствовалась на способах защиты периметра, таких как фаерволы, демилитаризованные зоны(DMZ) и бастион-хостов для защиты приложений и данных расположенных внутри сети организации. Данные способы защиты периметра абсолютно необходимы и критичны, однако с приходом глобализации и изменяющегося ландшафта по которым движется бизнес сегодня, в котором возникает необходимость разрешать доступ к внешним системам и приложениям, границы, разделяющие наши внутренние системы и приложения от внешних понемногу утончяются и размываются. Этот метод гарантирует что хосты (системы), на которых работает наше ПО лучше защищено и охраняется. Необходимость открывать наши сети и безопасно давать доступ требует от наших приложений (ПО) соразмерного усиления, вдобавок к сетевому или периметровому контролю безопасности.
Защищенные приложения, работающие на защищенных хостах (системах) в защищенных сетях является основным требованием. Потребность заключается в целостной безопасности, которая является первой и самой важной концепцией безопасности программного обеспечения, с которой нужно быть знакомой. Важным моментом служит понимание того, что ПО безопасно лишь настолько, насколько безопасно самое слабое звено в нём. В современных условиях, ПО редко развертывает как stand-alone бизнес-приложение. Часто оно комплексное, работает на хостах, которые связаны в несколько разных системах в сети. Слабость(уязвимость) в одном из этих слоев может привести к тому, что все меры (защиты и противодействия) будут бесполезны. Приложение, хост и сеть должны быть защищены адекватно и надлежиащим образом. Например, SQL-инъекция в приложении может позволить атакующему скомпрометировать сервер баз данных (хост) и запустить эксплойты от хоста, которые будут воздействовать на всю сеть. Подобным образом, открытый порт в сети может приводить к исследованию и эксплуатации хостов и уязвимостей в приложениях, которые не были своевременно обновлены(пропатчены). Безопасное ПО характеризуется защитой приложений, хостов и сетей в полном объёме таким образом, что не существует слабого звена, как например Ахиллесова Пята на Рис. 1.1.
Несмотря на понимание того факта, что безопасность сетей, систем и ПО критически важно для работоспособности и устойчивости организации или бизнеса, сегодняшняя вычислительная экосистема выглядит зачумленной изобилием небезопасных сетей и систем и в частности небезопасным ПО. В сегодняшей экосистеме, где ПО изобилует уязвимостями чему свидетельствуют публичные списки уязвимостей, базы данных багов и отчеты по инцидентам безопасности, безопасность не должна быть упущена из виду, что к сожалению не так. Некоторые из основных причин почему небезопасное ПО превалирует сводятся к следующему:
Тройственная ограниченность(iron triangle constraints)
Безопасность задним числом (security as an afterthought)
Безопасность против Юзабилити (Security versus Usability)
С момента зарождения задачи для решения бизнес-проблемы при помощи ПО до того времени пока решение будет спроектировано, разработано и развернуто, необходимо учесть время(расписание), ресурсы (область задач) и стоимость(бюджет). Ресурсы (люди) с подходящими навыками и техническими знаниями не всегда доступны и дорого стоят. От защитника ожидается роль вигиланта 24x7, защищающегося от всех атак, будучи скованым обязательствами, в то время как атакующему требуется быть способным проэксплуатировать одну уязвиомсть и атаковать в любое время, без необходимости играть по правилам. Вдобавок, в зависимости от бизнес модели или типа организации, разработка ПО может включать множество заинтересованных сторон(стейкхолдеров). Если не сказать больше, разработка ПО сама по себе является ресурсоёмким, сжатым в сроках работ и бюджетозатратным процессом. Добавим сюда тот факт, что корпоративная безопасность в ПО видится необходимостью делать "больше" вместо того чтобы сделать "меньше" или эффективнее. Ограничения областью задач, сроками работ и бюджетом, показаными на Рис.1.2 как компонентами Железного Треугольника, часто являются причинами, по которым требования безопасности выносятся из ПО. Если область задач проекта, время работ и бюджет установлены жёстко(как это часто бывает), не остается пространства для внедрения даже базовых, не говоря уже о дополнительных требованиях безопасности в ПО и к сожалению, чаще всего упускают из вида элементы безопасности ПО.
Разработчики и менеджмент предпочитают думать, что безопасность не добавляет бизнес-ценности, поскольку не так легко показать один в один результаты инвестиций в безопасность. Ограничения Железного треугольника часто приводят к добавочной безопасности, прикрученной к ПО и не внедренной в ПО. Крайне важно, чтобы компоненты безопасности разрабатывались внутри ПО, вместо того, чтобы быть добавленными на поздних этапах, поскольку доказано, что стоимость исправления небезопасного ПО на ранних стадиях процесса разработки (SDLC) незначительна по сравнению с той же самой ошибкой на поздних этапах, как изображено на Рис. 1.3. Исправление уязвимостей перед релизом продукта обходится гораздо дороже.
Другая причина, по которой внедрение компонентов безопасности в ПО - это испытание, в том, что подобное внедрение часто видится как способ сделать ПО очень сложным, неюзабельным и с множеством ограничений. Например, организации, занимающейся трудовыми ресурсами требуется возможность видеть данные по зарплатам сотрудников, и команду разработки попросили разработать внутренний веб-ресурс, к которому будет иметь доступ сотрудники HR-отдела. В тот момент, когда команда разработки консультируется со специалистом по безопасности, который является CSSLP, специалист рекоммендует разрешить доступ только тем кто аутентифицирован и авторизован и все запросы доступа должны журналироваться с целью анализа. Кроме того, преисполненный чувством того, чтобы всё было безопасно, специалист рекомендует команде разработки убедиться в том, что требования к аутентификации включают использование паролей, по меньшей мере в 15 символов, включающих в себя верхний и нижний регистр и содержащих буквенные, цифровые и спецсимволы, которые к тому же будут сбрасываться каждые 30 дней. Единожды спроектированное и разработанное, ПО разворачивается для использования HR-организацией. Быстро становится очевидным, что сотрудники HR-отдела записывают свои сложные пароли на стикерах и оставляют их в небезопасных местах, например в ящике письменного стола, или, в некоторых случаях на своих системных мониторах. Они также жалуются, что ПО невозможно использовать, поскольку каждый запрос доступ занимает много времени для обработки, так как все запросы доступа не только проверяются на авторизацию, а также аудируются(логируются). Нет никаких сомнений что внедрение безопасности осуществляются ценой производительности и юзабилити. Это правда, если дизайн ПО не учитывают концепцию, известную как психологическая приемлимость. Безопасность ПО должна балансировать между юзабилити и производительностью. Мы рассмотрим "Психологическую приемлимость" в деталях наравне с многими другими концептами дизайна в главе Дизайн безопасного ПО.
В мире, который руководствуется необходимостью и требованиями к качеству продуктов важно важно определять различия между качеством и безопасностью, в особенности применимо к программным продуктам. Почти все программные продукты проходят через фазу проверки качества(или тестирования) перед тем как пройти релиз или быть развернутыми, при этом функциональность ПО, требуемая бизнес клиентом или заказчиком, проверена и подтверждена. Проверки качества показательны для определния того, что ПО надежно в эксплуатации(функционирует в соответствии с дизайном) и функционально(соответствует требованиям, предъявленным владельцем бизнеса). Соответствие процессам Общего Менеджмента Качества(Total Quality Management - TQM), таким как шесть сигма (Six Sigma (6 σ)) или сертификация ПО в соответствии со стандартами качества ISO важно для создания ПО хорошего качества и достижения грани конкурентоспособности на рынке, однако важно осознавать, что данные проверки качества и сертификации необязательно означают то, что программный продукт защищен. Защищенный программный продукт добавит ПО качества, однако обратное не всегда верно.
Также важно понимать, что наличие функциональности безопасности в ПО может позволить поддерживать стандарты сертификации касчества, но необязательно влияет на защищенность ПО. Вендоры часто спекулируют наличием функциональности безопасности в ПО для того чтобы выделиться среди конкурентов и не смотря на то, что это может быть правдой, нужно понимать, само по себе наличие функциональности безопасности в вендорском ПО не делает его защищенным. Это происходит из-за того, что функциональность безопасности может быть не сконфигурирована для вашего рабочего окружения или, может быть внедрена некорректно. Например, ПО с функциональностью логирования всех критических и администраторских транзакций может быть сертифицироано как качественный безопасный продукт, однако до тех пор пока опция логирования транзакций не включена, она ничего не добавит к вашей безопасности. Поэтому чрезвычайно важно, чтобы вы проверяли все заявленные возможности вендоров внутри своей инфраструктуры и рассматривали любые проблемы, с которыми вы можете столкнуться, перед покупкой. Другими словами, доверяй, но проверяй. Это важно при оценку программного обеспечения вне зависимости от того, покупает вы его или разрабаваете сами.
Для разработки программного обеспечения, защищенного от взлома, важно включить концепции безопасности на этапах SDLC, таких как: разработка требований, дизайн, написание кода, релиз и вывод из эксплуатации. Концепты безопасности располагаются вокруг всего жизненного цикла продукта и должны быть внедрены в каждый этап. Требования к безопасности ПО, дизайну, разработке и развертыванию должны принимать во внимание все концепты безопасности. Недостаток или неэффективность внимания на одном этапе может сделать тщетными все усилия, предпринятые в остальных этапах. Например, выдвижение требований по осущствлению защиты от раскрытия информации(конфиденциальности) на этапе сбора требований вашего SDLC, но не на этапе дизайна потенциально может привести к возможностям утечки информации.
Основной план для вашего ПО с точки зрения безопасности в создании профиля безопаснотси для ПО и внедрение этих концептов в SDLC. Как показано на Рис. 1.4, некоторые из этих концептов могут быть классифицированы как ключевые концепты безопаснотси, в то время как остальные являются основными, либо дизайн-концептами безопасности. Как бы то ни было, данные концепты безопасности являются необходимы блоками для построения безопасной разработки ПО. Другими словами, они являются открытыми потребностями, которые необходимо учитывать, и которые нельзя игнорировать.
Следующая глава раскрывает данные концепты безопасности на вступительном и разъяснительном уровнях. Они будут расширены в последующих главах в рамках каждого домена.
