Microsoft SDL: Return-on-Investmentdownload.microsoft.com/Documents/rus/msdn/MicrosoftSDL... · Web...

Microsoft SDL. Microsoft SDL: Return-on-Investment19 января 2010 г.Последние сведения см. на веб-сайте http://www.microsoft.com/sdl.

http://www.microsoft.com/sdl

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

Содержащиеся в документе сведения отражают текущую позицию корпорации Майкрософт и компании iSEC Partners, Inc. (в дальнейшем «авторов») в отношении обсуждаемых вопросов на момент публикации. Поскольку авторы должны реагировать на изменение рыночных условий, документ не может рассматриваться как обязательство со стороны авторов и авторы также не гарантируют точности представленных сведений после даты публикации.

© Корпорация Майкрософт и компания iSEC Partners, Inc., 2009. Все права защищены. Microsoft является товарным знаком группы компаний Майкрософт. Использованные в документе названия реальных компаний или продуктов могут быть товарными знаками соответствующих владельцев.

Данная работа лицензирована по лицензии Creative Commons «Attribution-Non-Commercial License» (некоммерческая лицензия Creative Commons с обязательной ссылкой на источник). Чтобы ознакомиться с текстом этой лицензии, обращайтесь на веб-сайт http://creativecommons.org/licenses/by-nc/2.5/ (на английском языке) либо пишите по адресу: Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA (США).

Оценка рентабельности инвестиций в структурированную программу безопасности22

http://creativecommons.org/licenses/by-nc/2.5/

http://creativecommons.org/licenses/by-nc/2.5/

АННОТАЦИЯСокращение бюджетов в период экономического спада нередко вынуждает пересматривать расходы на программы безопасности. Рентабельность инвестиций (ROI) в обеспечение безопасности не всегда очевидна по следующим причинам.

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

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

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

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

безопасности программного обеспечения и рассказать о них коллегам; в целях совершенствования процесса разработать и использовать показатели

рентабельности инвестиций; достигнуть значительных результатов с использованием новой программы или

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

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

1. Устранение уязвимостей на ранних этапах ведет к снижению общих затрат на разработку и средства поддержки.

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

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

Оценка рентабельности инвестиций в структурированную программу безопасности 1

ВВЕДЕНИЕПрограммное обеспечение играет жизненно важную роль в обеспечении деятельности современных организаций. И хотя все больше компаний приходят к пониманию значимости безопасных систем, безопасность программного обеспечения по-прежнему вынуждена отвоевывать себе «место под солнцем» во все более ограниченных бюджетах предприятий. Поэтому ИТ-руководителям необходимо отчетливо представлять себе, почему и как оправдываются инвестиции в безопасность программного обеспечения. В этом техническом документе показано, что оптимально разработанная программа безопасности способна снизить общие затраты на разработку приложения и связанные с ним бизнес-процессы.В настоящем документе рассматривается обоснование безопасности ПО с точки зрения возврата инвестиций за счет четкой программы обеспечения безопасности. Зачастую организации недооценивают потенциальный вклад безопасности в конкурентоспособность предприятия. Редко используются инструменты, помогающие понять важность такого вклада. Менеджеры могут использовать показатели рентабельности инвестиций и безопасности в составлении экономического обоснования программ безопасности ПО, убедительно демонстрируя, как достичь значительных улучшений в рамках приемлемого бюджета. Огромный бюджет или масштабные структурные изменения вовсе не обязательны для разработки эффективной программы безопасности ПО. Гораздо важнее структурированный подход и изменение культуры ведения разработки. Существуют доступные способы, благодаря которым технические работы по обеспечению безопасности позволяют организации шаг за шагом достичь максимальной эффективности. Устранение уязвимостей в нужной стадии жизненного цикла ПО помогает добиться экономии за счет сокращения времени разработки.

БЕЗОПАСНОСТЬ. ПОЧЕМУ ЭТО ВАЖНО ДЛЯ ВАСБезопасность способствует всестороннему росту эффективности и рентабельности инвестиций, поэтому вложения в безопасность нельзя отнести к невозвратным затратам. С повышением безопасности системы уменьшаются стоимость реагирования на инцидент и число нарушений бизнес-процессов. Четко организованная программа безопасности ПО снижает издержки и риски в системах обеспечения безопасности и при соблюдении установленных нормативов. И наконец, эффективные меры безопасности, внедренные в жизненный цикл разработки ПО, сокращают затраты на уязвимости (как в безопасности, так и в других сферах) за счет более высокого качества в целом.Нарушения безопасности непредсказуемы и требуют для ликвидации значительных затрат, и сегодня любое приложение может стать мишенью для них. Реагирование на нарушение безопасности влечет за собой прямые затраты, включая расходы на следующие меры:

выявление текущей уязвимости; определение скомпрометированных систем; восстановление скомпрометированных систем;


информирование заказчиков. Затраты на необходимое расследование и последующее исправление нарушений бизнес-процесса могут быть значительными. В 2008 г. расходы организаций при нарушениях конфиденциальности информации составили в среднем 202 долл. на каждого заказчика и 6,6 млн долл. на каждый случай1. Эти цифры включают в себя оценку косвенных затрат, в то время как воздействие на репутацию организации, утрата доверия заказчиков и потеря клиентов чреваты гораздо более пагубными последствиями, в особенности если специфика отрасли требует публичной огласки крупных инцидентов. Прочие типы нарушений безопасности, такие как утрата значимой интеллектуальной собственности или крах бизнеса, могут обойтись намного дороже — настолько, что это порой невозможно ни оценить, ни учесть в бюджете.Даже если подобные инциденты представляются чем-то не слишком вероятным, перспективы расходования средств на безопасность намного лучше «сценариев апокалипсиса». Инвестиции в безопасность можно спрогнозировать и заложить в бюджет. А риск непредвиденных затрат в условиях всеобщего сокращения бюджетов и финансового кризиса, с одной стороны, и высокой степени нарушений безопасности, с другой, сегодня вряд ли коммерчески оправдан. К тому же, согласно прогнозам число компьютерных преступлений будет только возрастать.Как правило, организациям с более развитыми программами безопасности приходится прилагать намного меньше усилий для соответствия новым нормативным требованиям. Обычно неподготовленным предприятиям довольно дорого обходится соответствие нормативам, тогда как согласно прогнозам в ближайшие годы сохранится тенденция к дальнейшему расширению и ужесточению нормативной базы. Поэтому разработка программы безопасности в соответствии с потребностями организации, обладая непосредственными выгодами, может к тому же обеспечить стратегические преимущества, к которым обычно так стремятся неподготовленные участники рынка.Целью структурированного подхода к безопасной разработке является, прежде всего, улучшение качества и повышение надежности систем. Намного дешевле устранить уязвимости, обнаруженные и откорректированные до сдачи готового продукта. К тому же более безопасные системы требуют меньше обновлений и расходов в процессе эксплуатации. Снижается вероятность вынужденных простоев и ошибок в текущем бизнес-процессе независимо от того, подвергается ли система атакам.

ПОЧЕМУ СТРУКТУРИРОВАННЫЙ ПОДХОД СПОСОБСТВУЕТ ВЫСОКОЙ РЕНТАБЕЛЬНОСТИ ИНВЕСТИЦИЙУ организаций, начинающих работу с программами разработки безопасного ПО, нередко возникает соблазн перенести тестирование системы безопасности на окончание процесса разработки. В этом случае намного проще планировать бюджет и

1 Согласно ежегодному исследованию в США в 2008 г. «Расходы при нарушении конфиденциальности данных»,

проведенному Институтом Понемона и корпорацией PGP.


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

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

Рассмотрим дефицит безопасности на уровне требований. Достичь безопасности можно в несколько различных этапов, в зависимости от того, на каком уровне находится безопасность в данный момент. Хотя во всех случаях график может сместиться и для его корректировки потребуются дополнительные ресурсы, размер затрат в значительной мере определяется достигнутым этапом безопасности. Точные 2 Согласно отчету NIST от 2002 г. «Экономическое воздействие не соответствующей требованиям инфраструктуры на

испытание ПО».


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

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


Не бывает панацеи от всех проблемЗлоумышленнику достаточно обнаружить в системе всего лишь одну уязвимость и воспользоваться ею, тогда как защитнику надо найти и устранить как можно больше уязвимостей до тех пор, пока не будет достигнут необходимый уровень гарантии безопасности системы. В отчете Майкрософт Security Intelligence Report (SIR) показано, что подавляющее большинство уязвимостей обнаруживается в приложениях, а не в обозревателях или ОС3. Разработчикам приложений как в крупных, так и в мелких проектах необходимо инвестировать в деятельность, направленную на обеспечение безопасности. При отсутствии структурированного процесса группе разработки трудно понять, насколько полноценно обеспечивается безопасность. Точно так же в отсутствие структурированного процесса руководство не может отследить полноту обеспечения безопасности в семействе приложений или необходимый уровень гарантии безопасности. Независимо от качества отдельных мер безопасности именно структурированный подход способствует надежности и функциональности процессов. Кроме того, структурированный процесс создает основу для дальнейшей работы, позволяя измерять и улучшать качество отдельных видов деятельности.Существует еще одно важное следствие неравных возможностей злоумышленников и защитников. Панацеи на все случаи не бывает. Многие предлагаемые на рынке продукты безопасности позиционируются как способные «устранить» проблемы безопасности ПО. Некоторые из этих продуктов чрезвычайно полезны группам безопасности, использующим их с полным пониманием реальных возможностей этих продуктов. При правильном применении эти продукты способны повысить эффективность имеющихся ресурсов, но нельзя полагаться только на них, также как невозможно эффективно пользоваться ими без дополнительных вложений времени, знаний и опыта. У всех подобных инструментов имеются «мертвые зоны». К примеру, злоумышленник может воспользоваться пробелами в правилах бизнеса так, что его невозможно будет отличить от зарегистрированного пользователя.Все эти инструменты находят свое место в полностью структурированном подходе. В зависимости от потребностей организации и возможностей бюджета целесообразно внедрять их на различных этапах. Однако необходимо понимать, что ни один из продуктов никогда не сможет заменить разработку безопасного ПО. Непременные условия безопасности — это специалисты, профессионалы и крупные организации по разработке, а также изменение культуры разработки в направлении безопасности, эффективные и своевременные инструменты, реализация безопасности в духе совместной работы всех составляющих и набор показателей, позволяющий совершенствовать сам процесс и его понимание.

КАК КОНТРОЛИРОВАТЬ СИТУАЦИЮ В УСЛОВИЯХ СОКРАЩЕНИЯ БЮДЖЕТОВДовольно часто, когда речь заходит о сокращении бюджета, меры безопасности признаются не столь существенными. К сожалению, до тех пор пока существуют небезопасные приложения, сохраняется риск, который они представляют для бизнес-процессов. Более того, по мере старения приложений и появления новых видов атак необновляемые приложения подвергаются повышенному риску уязвимостей для эксплойтов. Еще важнее поддерживать культуру безопасности. Если деятельность по обеспечению безопасности осуществляется в организации нерегулярно, группы

3 http://www.microsoft.com/sir


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

КАК ОБОСНОВАТЬ ЦЕЛЕСООБРАЗНОСТЬ ИНВЕСТИЦИЙ В БЕЗОПАСНОСТЬПрибегая к мерам безопасности, каждая организация преследует собственные цели. Необходимо четко обозначить цели инвестирования, чтобы точно знать, отвечают ли инвестиции в безопасность своему предназначению. Как правило, первоочередная цель организаций заключается в сокращении случаев нарушений бизнес-процессов. Это легко подсчитать с помощью моделирования угроз и соответствующих видов деятельности. Целью инвестирования в обучение может быть уменьшение числа уязвимостей в системе безопасности, тогда как целью инвестиций в моделирование угроз может быть улучшение соотношения числа уязвимостей, обнаруженных во время разработки и на более поздних этапах. Определив цели мер безопасности, можно наметить методы измерения, а также порядок подсчета выгоды в виде рентабельности инвестиций.Хотя показатели безопасности — относительно новая область, четко представляя желаемые выгоды, можно разработать хорошие показатели, которые будут служить постоянным инструментом для поддержки принятия решений и обоснования бюджета. Каждая организация преследует свои цели. Чтобы отслеживать эти цели и поддерживать необходимые решения, организации понадобятся различные показатели.Создание или отслеживание показателей должно быть недорогим. Как правило, наилучшими являются самые простые показатели, которые точно отражают нужную информацию. Для сложных показателей может потребоваться гораздо больше работы, и зачастую они недостоверны в силу неточности заложенных в них предположений. Чтобы хорошо представлять рентабельность инвестиций в безопасность, для начала надо понять, чего мы хотим избежать. Например, каждое потенциальное нарушение бизнес-процесса может быть связано с определенными, заранее подсчитанными затратами на восстановление. Имеет смысл рассмотреть каждое действие по обеспечению безопасности и разобраться, как оно сможет уменьшить количество потенциальных нарушений бизнес-процесса и какова будет экономия. Используя эти


две — исходную и результирующую — стоимости и коэффициент сравнения, можно определить рентабельность инвестиций. В идеальном мире коэффициент сравнения был бы достоверной вероятностью, но значимых вероятностей для этой цели не существует. Организациям в среде с высокой вероятностью угроз и с особо важными целями (таким, как Майкрософт) следовало бы работать, допуская, что все уязвимости в конце концов будут обнаружены и использованы злоумышленниками. Однако большая часть организаций вынуждена устанавливать планку разумных ограничений.В идеале все показатели безопасности должны быть конкретными и связанными с определенными бизнес-процессами, но такой вид анализа, ориентированный на бизнес, не всегда возможен. К счастью, обычно достаточно упрощенных показателей. Количество обнаруженных и устраненных уязвимостей — это хороший начальный показатель успешности мер безопасности, нацеленных на обнаружение уязвимостей. При сравнении приложений важно оценивать этот показатель в контексте зрелости безопасности приложения и трудозатрат, связанных с обнаружением уязвимостей. Для достижения большей точности показателя следует соотнести уязвимости с предполагаемой средней стоимостью или затратами на устранение последствий вмешательства в наихудшем сценарии, что может оказаться полезным при сравнении систем.Полезным показателем для мер безопасности в процессе разработки может быть также количество нарушений политики безопасности, например использование известных небезопасных прикладных программных интерфейсов (API). Весьма эффективный шаг — подсчитать экономию в результате обнаружения или предупреждения проблем в начале процесса разработки и сравнить сэкономленные средства с затратами на корректировку возникшей проблемы в производстве. Чтобы наладить доверительные взаимоотношения с организациями, где рабочие группы ответственны за расходы на меры безопасности, но не несут непосредственной ответственности за результаты, можно обосновать сокращение расходов в свете ключевого индикатора производительности этих групп, таких как необходимость привлечения разработчиков или отсутствие срывов в графике работ.Соответствующие каждому этапу показатели можно использовать для создания стимула постепенного встраивания безопасности в проект. Эти показатели должны отслеживаться как в краткосрочном плане, так и в долгосрочной перспективе. В краткосрочном плане они являются источником сведений о конкретных проектах. В долгосрочном — предоставляют сведения об уровне зрелости организации.Различные типы мер безопасности по-разному окупаются. Непосредственным критерием служат виды деятельности по обеспечению безопасности, предпринятые после разработки и выявившие уязвимости. Меры безопасности до разработки, включая обучение, обнаруживают уменьшение числа уязвимостей, содержащихся в системе. Показатели должны способствовать выяснению неопределенностей (например, отвечать на вопрос о качестве обучения или проверки). Трудности могут возникнуть с определением того, какой показатель отображает данные без дополнительной информации. Попробуйте сравнить приложения групп, сотрудники которых прошли или не прошли обучение безопасности. Или попробуйте рассмотреть, как изменения в типах обнаруженных в приложении уязвимостей соотносятся с обучением, которое прошла группа.Хотя показатели используются в первую очередь для оценки краткосрочной безопасности и совершенствования долгосрочного процесса, они также могут стать


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

КАК ИЗВЛЕЧЬ МАКСИМАЛЬНУЮ ВЫГОДУ ИЗ ИНВЕСТИЦИЙЭффективное выполнение мер безопасности способствует достижению максимальной рентабельности инвестиций. Если в компании уже действуют определенные меры безопасности, но вы стремитесь к более эффективному распределению ресурсов, можно прибегнуть к следующим шагам.

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

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

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

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

Повысьте зрелость процессов в организацииОрганизации с высокой зрелостью процессов безопасности создают более безопасное ПО, требуя меньшего участия центральной группы безопасности. Также они расходуют меньше ресурсов на повторные изменения процессов и в связи с недостаточным знанием процессов, выпуская более стандартизированный и простой в освоении продукт. Залогом долгосрочного успешного повышения зрелости организации является эффективный план по совершенствованию процессов. Модель оптимизации жизненного цикла безопасной разработки Майкрософт (SDL)4 является превосходным ресурсом для определения эффективных мер безопасности. Она также полезна в оценке текущего состояния и получении нормативного руководства по структурированному началу или повышению зрелости программы безопасности. В документах «Создание безопасности в зрелой модели» (Building Security In Maturity Model)5 и «Программа Software Assurance для зрелой модели» (Software Assurance

4 См. на веб-сайте MSDN: http :// msdn . microsoft . com / en - us / security / dd 221356. aspx .

5 См. на веб-сайте: http://www.bsi-mm.com/.


http://www.bsi-mm.com/

http://msdn.microsoft.com/en-us/security/dd221356.aspx

Maturity Model)6 предлагаются альтернативные способы определения зрелости безопасности в организации.Если вы не готовы пока перенять полную модель повышения зрелости, можно начать с нескольких ключевых мер, подготавливающих основу для зрелой программы безопасности, включая обучение, стандарты и политики организации, а также управление самой программой безопасности.Обучение представляет собой исключительно важный компонент зрелости организации. Сотрудникам, занятым в программах безопасности, необходимо хорошо разбираться в работе, которая им предстоит. Обучение должно не только охватывать основы безопасности (распознавание уязвимостей и профилактику их появления), но и разъяснять самой широкой аудиторий стандарты, процедуры и ответственность за безопасность, специфичные для конкретной организации. В стартовый комплект разработчика Microsoft SDL (на английском языке) входит подборка базовых обучающих материалов по безопасности для разработчиков, помогающих организациям начать работу.Стандарты и политики содержат основную необходимую информацию. Сложные и всесторонние стандарты не всегда эффективны или не эффективнее базовых стандартов. В стандартах приведены технические сведения для рабочей группы о том, как разрабатывать безопасные приложения, включая запрещенные API, обязательные рекомендации и предупреждение различных видов уязвимостей. Политики посвящены обсуждению высокоуровневых проблем в процессе разработки, а также обработке различных классификаций данных в системах, реализующих различные категории бизнес-процессов, и обеспечению безопасности систем, взаимодействующих с различными типами окружений. Эффективные стандарты являются для архитекторов и группы безопасности отправной точкой для начала работы по оценке приложений и созданию требований, необходимых для обеспечения безопасности. Эффективные стандарты также предоставляют разработчикам и специалистам по тестированию ресурсы для дальнейших действий в соответствии с этими документами. Подобным образом политики позволяют получить общее понимание о работе процессов и помогают группе разработки обозначить видимые очертания проблем.Хорошее управление — это ключ к программе безопасности высокого уровня. Процессы, связанные с отслеживанием проблем, документацией и назначением ответственных, следует формировать совместно с группами, на которые они окажут влияние, и в соответствии с текущей политикой. Существуют значительные различия среди организаций в распределении ролей, необходимых для взаимодействия разработки и безопасности, а также в назначении конкретных обязанностей для каждой из групп. Более подробная информация на эту тему содержится в описании моделей зрелости. Однако для долгосрочного успеха мер безопасности очень важно, чтобы итоговое соглашение всех устраивало бы и было бы всем понятно. Основные моменты соглашения содержат назначение ответственных за выполнение заданий, распределение ресурсов между разработкой и безопасностью, отслеживание уязвимостей и приложений, а также разделение полномочий между группами.6 См. на веб-сайте: http :// www . opensamm . org / .


http://go.microsoft.com/?linkid=9672891

http://go.microsoft.com/?linkid=9672891

http://www.opensamm.org/

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

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


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

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


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

Получите именно то, за что заплатилиЗачастую организации при расходовании средств на безопасность приобретают не то, что было оплачено, будь то покупка услуг и инструментов либо проведение внутренних мероприятий.В то время как деятельность, направленная на повышение зрелости организации и высокоуровневый предварительный анализ, почти всегда окупается, меры безопасности на уровне кода являются более сложными с точки зрения рентабельности инвестиций.Организации порой накладывают ненужные ограничения на рабочие группы, занимающиеся поиском уязвимостей, препятствуя их эффективности и не используя ценные ресурсы. Предоставьте внутренним и внешним группам тестирования все, что необходимо для работы, как можно быстрее и в максимально полной форме, включая исходную программу, тестовую систему, внутреннюю документацию и доступ к получению информации разработчиками. Помните, что защитники должны найти все уязвимости, тогда как злоумышленникам достаточно обнаружить лишь одну. Более того, не все злоумышленники будут посторонними лицами. Неверно считать, что функциональное тестирование на уровне «черного ящика» наилучшим образом воспроизводит точку зрения злоумышленника. У вас есть одно серьезное преимущество: вы знаете систему изнутри. Извлеките из этого максимальную пользу.Автоматизированные инструменты тоже могут не оправдать ожиданий. Их следует оценивать с позиций практического понимания предоставляемых ими возможностей и в свете фактической общей стоимости, включая оплату труда сотрудников, обучение и настройку. Первоначальная стоимость может быть высокой, но еще выше издержки на постоянное конфигурирование и обслуживание этих инструментов, а также обработку полученных результатов. К тому же они являются только частью процесса безопасности, а не готовым комплексным решением. С помощью доступных бесплатных инструментов оцените затраты и способность организации эффективно использовать более сложный и дорогой инструмент.В контексте мер, ориентированных на рентабельность инвестиций, ваши показатели должны предоставлять информацию об относительной полезности различных мер. Обратите внимание на эти показатели. Эффективные показатели помогут оптимизировать процессы и получить именно то, за что было заплачено.

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


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

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

Существующая мера Стоимость

Новая мера Стоимость

Используемые показатели

Обучение безопасному кодированию 100 разработчиков/год

200 000 долл.

Всестороннее обучение 20 архитекторов/год

100 000 долл.

Разница в уязвимостях, связанных с требованиями и архитектурой

Обучение стандартам и политикам 300 разработчиков/год

40 000 долл.

Разница в соответствиях стандартам





Годовая лицензия на сканер исходного кода

50 000 долл.

Зарегистрированные подтвержденные уязвимости

Разница в уязвимостях при полном анализе аналогичных приложений

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

10 000 долл.

Разница в уязвимостях для охватываемых типов проблем

Планирование реагирования на нарушение безопасности

5000 долл.

Разница в затратах на нарушение безопасности с учетом общепринятого в отрасли времени реагирования

Коммуникации и планирование процесса

5000 долл.

Разница в затратах на эквивалентные меры безопасности

Отслеживание показателей в масштабе предприятия

10 000 долл.

Отсутствуют

Прежняя общая стоимость

200 000 долл.

Новая общая стоимость 220 000 долл.

Меры безопасности в масштабе проекта




Функциональное тестирование на проникновение для 20 проектов/год

1200 000 долл.

Рецензирование безопасности с полным доступом для 10 проектов/год

800 000 долл.

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

Анализ требований для 20 проектов/год

80 000 долл.

Уязвимости безопасности на уровне требований, относительный риск проекта, оценка стоимости нарушения бизнес-процесса





Анализ безопасности/моделирование угроз для 20 проектов/год

120 000 долл.

Уязвимости безопасности на уровне архитектуры, относительный риск проекта

Создание инструкций по безопасности для 20 проектов/год

40 000 долл.

Разница в уязвимостях для охватываемых типов проблем в сравнении с аналогичными приложениями

Отслеживание уязвимостей в безопасности

20 000 долл.


Отслеживание показателей проекта

20 000 долл.


Прежняя общая стоимость

1200 000 долл.

Новая общая стоимость 1080 000 долл.

Основываясь на этих данных, можно рассматривать рентабельность инвестиций для конкретной составляющей. Хотя некоторые из пунктов проанализировать сложнее, анализ требований является хорошей отправной точкой. Цель системы отслеживания мини-приложений (Widget Tracking System) — управлять выполнением заказа для внутренней цепочки поставок. Сторонние поставщики взаимодействуют напрямую с системой. Анализ требований обнаруживает десять различных нарушений бизнес-процесса, представляющих интерес, а оценка стоимости каждого нарушения составляет от 10 000 до 150 000 долл. Из них пять можно полностью предупредить путем проверок и соотношений, выполненных на уровне требований. Три из них повлекли незначительные затраты либо обошлись совсем без затрат, а оставшиеся два обошлись примерно в 100 долл. периодических расходов на каждую операцию. Легче выбрать низкозатратные варианты, но чтобы определить целесообразность более затратных вариантов, следует знать частоту возникновения реальных угроз нарушения операций.К сожалению, здесь нет способа подсчета простой вероятности. Для конкретных расчетов необходимы дополнительные представления о круге потенциальных злоумышленников. Что нам известно, так это суммарная трудоемкость, необходимая для осуществления атак злоумышленником, и относительная сложность этих атак. Оба параметра являются достоверными показателями, и в отсутствие любой информации о том, случится ли атака, единственное ответственное действие защитника — это предположить, что атака состоится, и наметить меры по реагированию в соответствии с ее сложностью.


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

НАЧАЛО С НУЛЯ И С НЕБОЛЬШИМ БЮДЖЕТОМПервоначальные меры обеспечения безопасности ПО могут потребовать меньше ресурсов и усилий, чем кажется. Можно начать с относительно небольшими ресурсами и в итоге получить хорошие результаты, обладая поддержкой руководства. Обосновывать вкладываемые ресурсы становится легче по мере того, как работа начинает окупаться. Для эффективного прогресса важно иметь хотя бы небольшую поддержку со стороны руководства. Эту поддержку легче получить, ограничив требования на начальные ресурсы и составив четкий план по измерению рентабельности инвестиций. Могут также пригодиться некоторые из моделей по усовершенствованию текущей работы, описанные в этом документе выше. Хорошей отправной точкой послужат следующие шесть мер.

Перед тем как приступить к структурированию процесса, составьте четкий план.

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

Тщательно отбирайте экспериментальные проекты, обращая внимание на управление рисками.

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

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


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

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


Управляйте риском и выберите экспериментальный проектПриступая к новой программе безопасности, тщательно отбирайте первые проекты. Даже если собираетесь активизировать программу так, чтобы охватить все проекты в пределах организации, начать следует с экспериментального проекта. Считайте проект с риском безопасности пилотным. Проект с риском безопасности увеличивает вероятность того, что будут найдены проблемы безопасности с отчетливым влиянием на бизнес, помогая обосновать будущие меры и отработать навыки и способствуя надлежащему использованию ресурсов прямо сейчас. Однако не имеет значения, насколько тщательно взвешен процесс (даже если вы можете предварительно обучить целую рабочую группу). В новых процессах всегда есть особенности, на разработку которых требуется время. Чтобы увеличить вероятность успеха экспериментального проекта, старайтесь не выбирать дорогой, очень значимый проект с жесткими временными рамками и ограниченными ресурсами.Чтобы принять решение относительно экспериментального проекта, необходимо определиться с относительным риском проектов. Ключевую роль в этом играют показатели. При оценке будущих проектов важна предварительная разработка показателей. Использование этих показателей с самого начала положительно повлияет на принятие проекта и позволит раньше увидеть тенденции, хотя иногда экспериментальные проекты должны быть исключениями. Например, установите планку, определяющую величину стоимости нарушения бизнес-процесса, при превышении которой проект обязательно подвергнется полному анализу и все приложения, которые будут размещены в общедоступной сети, пройдут как минимум базовый анализ.

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

Реагирование на нарушение безопасностиРеагирование на нарушение безопасности — не первоочередная задача при большом наборе ресурсов, но, как было упомянуто выше в разделе, посвященном


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

Обращайтесь за помощью к профессионаламПриступая к работе с небольшими ресурсами, важно обладать поддержкой опытных специалистов. Некоторые существующие программы, такие как модель оптимизации SDL (SDL Optimization Model), разработаны для оказания поддержки организациям с только что структурированной безопасностью (или структурированной в целом) в повышении зрелости процессов. Кроме того, во многих случаях во избежание ловушек в ходе процесса целесообразно привлекать сторонних консультантов, обладающих значительным опытом. Сотрудничество с хорошим консультантом поможет понять потребности организации, развить процессы, которые будут работать на вас, и даже обеспечить адаптированными к местным условиям стандартами и политиками. Более того, сторонние консультанты могут выполнять перекрестный контроль положительных сдвигов с позиций зрелости безопасности, как на уровне процесса, так и на уровне отдельной системы. Они могут калибровать используемые показатели и проводить выборочные проверки в определенных системах с помощью анализа приложений, даже если большинство задач по обеспечению безопасности решаются силами ваших сотрудников.

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


Меры безопасности в масштабе предприятия

Мера Стоимость


Интенсивное обучение пяти архитекторов/год

25 000 долл.

Разница в уязвимостях, связанных с требованиями и архитектурой

Обучение стандартам и политикам 50 разработчиков/год

10 000 долл.

Разница в соответствиях стандартам

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

5000 долл.

Разница в уязвимостях для охватываемых типов проблем

Планирование реагирования на нарушение безопасности

3000 долл.

Разница в затратах на нарушение безопасности с учетом общепринятого в отрасли времени реагирования

Коммуникации и планирование процесса

3000 долл.

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

Отслеживание показателей в масштабе предприятия

2000 долл.


Итого 48 000 долл.

Первоначальные меры безопасности в масштабе проекта



Анализ безопасности внешнего доступа для одного проекта

80 000 долл.


Анализ требований для трех проектов

16 000 долл.

Уязвимости в безопасности на уровне требований; оценка стоимости нарушения бизнес-процесса; улучшения качества проекта, не связанные с безопасностью

Анализ безопасности/моделирование угроз для трех проектов

15 000 долл.

Уязвимости в безопасности на уровне архитектуры; улучшения качества проекта, не связанные с безопасностью




Создание инструкции по безопасности для трех проектов

8000 долл.



2000 долл.


Отслеживание показателей проекта 2000 долл.



Окончательные меры безопасности в масштабе проекта



Анализ безопасности полного доступа для двух проектов/год

120 000 долл.


Анализ требований для пяти проектов/год

20 000 долл.

Уязвимости в безопасности на уровне требований; оценка стоимости нарушения бизнес-процесса; улучшения качества проекта, не связанные с безопасностью

Анализ безопасности/моделирование угроз для пяти проектов/год

30 000 долл.

Уязвимости в безопасности на уровне архитектуры; улучшения качества проекта, не связанные с безопасностью

Создание инструкций по безопасности для пяти проектов/год

10 000 долл.



2000 долл.


Отслеживание показателей проекта 2000 долл.



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


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

Уровень сложности

Требование / Разработка

Разработка

Интеграционный тест

Приемосдаточное испытание

Развертывание

Высокий 1000 долл. 3000 долл.

7000 долл. 15 000 долл. 80 000 долл.

Средний 1000 долл. 3000 долл.

7000 долл. 15 000 долл. 40 000 долл.

Низкий 1000 долл. 3000 долл.

7000 долл. 15 000 долл. 30 000 долл.

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

Мера Обнаруженные уязвимости Экономия в сравнении с ситуацией, когда эти уязвимости были бы обнаружены в готовой версии

Анализ безопасности внешнего доступа для одного проекта

2 высокого уровня сложности (80 000 долл. x 2) - (15 000 долл. x 2) +

3 среднего уровня сложности (40 000 долл. x 3) - (15 000 долл. x 3) +

10 низкого уровня сложности (30 000 долл. x 10) - (15 000 долл. x 2) +

Итого: 355 000 долл.

Анализ требований для трех проектов

1 высокого уровня сложности (80 000 долл. x 1) - (1000 долл. x 1) = 79 000 долл.

Анализ безопасности/моделирование угроз для трех проектов

1 среднего уровня сложности (40 000 долл. x 1) - (1000 долл. x 1) = 39 000 долл.


Мера Обнаруженные уязвимости Экономия в сравнении с ситуацией, когда эти уязвимости были бы обнаружены в готовой версии

Итого: 437 000 долл.

Стоимость работы: 123 000 долл.

Итого 3 высокого уровня сложности, 4 среднего уровня сложности, 10 низкого уровня сложности

473 000 долл. – 123 000 долл. = 350 000 долл. прибыль от инвестиций

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

Здесь мы рассмотрим другой пример рентабельности инвестиций, на этот раз в уравновешивании двух видов деятельности. Чтобы обосновать затраты на безопасность, необходимо использовать показатели с такими наименованиями, которые близки высшему руководству. В этом случае предположим, что показателем является количество уязвимостей. Чтобы оценить, что эффективнее — работа группы безопасности организации по выполнению анализа кода или привлечение сторонних консультантов, — можно сравнить затраты на каждый из вариантов. Предполагая, что использование внутренних ресурсов дешевле при меньшей квалификации, затем можно выполнить экспериментальные проекты (в идеале — с многочисленными вариантами, но это не всегда возможно) и посмотреть на результаты. Нужно оценить обнаруженные уязвимости по затратам времени и степени серьезности, используя систему стандартных рейтингов. Даже при наличии очень ограниченных данных у нас есть три возможных результата. Либо затраты на каждую уязвимость в двух проектах будут приблизительно сопоставимы, либо результаты в первом или во втором проекте будут существенно различаться. Результаты одного проекта могут не соответствовать норме, но если будущие меры не подтвердят эти результаты, наличие статистической базы позволит быстро увидеть разницу и сообщить эту разницу руководителям в удобном для них виде. Хотя такой метод не дает четкого ответа на вопрос, какую прибыль в денежном исчислении принес каждый инвестированный доллар, он позволяет получить данные более высокой рентабельности инвестиций, оцененной с точки зрения важных для организации выгод.


ЗАКЛЮЧЕНИЕПовышение безопасности системы делает ее более надежной и менее затратной в работе в различных аспектах. Тогда как меры по обеспечению безопасности ПО требуют вложения некоторых ресурсов, значительной рентабельности инвестиций нередко можно достичь даже с небольшими первоначальными затратами. Аккуратное применение показателей позволяет измерять влияние инвестиций. И те же самые метрики способствуют долгосрочному росту рентабельности инвестиций и общей эффективности безопасности.Структурированный подход к безопасности делает процесс более прогнозируемым, значительно повышает его эффективность и позволяет группе по обеспечению безопасности развертывать свои ресурсы наиболее продуктивно, «сверху вниз». Сочетание высокоуровневого и низкоуровневого видов анализа, основанных на показателях управления рисками, совместно с нужными инструментами способствует достижению наилучшей, измеримой рентабельности инвестиций. Если организации структурируют процесс разработки и прибегают к мерам обеспечения безопасности как можно раньше, затраты на устранение большинства уязвимостей значительно сокращаются. Хотя инструменты должны быть необходимым слагаемым успеха и способствуют повышению эффективности, ни один продукт не способен заменить собой процедуры безопасной разработки ПО. Эффективный, структурированный подход к безопасности ПО должен включать в себя людей (как профессионалов, так и более крупные организации по разработке), изменение культуры разработки в направлении безопасности, при необходимости – инструменты, процессы безопасности для связки видов деятельности и показатели, способствующие пониманию и совершенствованию.Показатели безопасности из всех указанных элементов важнейшие. Они предоставляют средства для понимания влияния отдельных мер безопасности, чтобы со временем сбалансировать расходы на ресурсы, улучшить процессы безопасности и повысить уровень зрелости организации. Инвестиции в четко организованную, структурированную безопасность всегда себя оправдают.


Microsoft SDL: Return-on-Investmentdownload.microsoft.com/Documents/rus/msdn/MicrosoftSDL... · Web...

Documents

Transcript of Microsoft SDL: Return-on-Investmentdownload.microsoft.com/Documents/rus/msdn/MicrosoftSDL... · Web...