БЕЗОПАСНОСТЬ

Путь к безопасному по лежит через архитектуру, автоматизацию и аутсорсинг

Камерон Стардевант

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

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

Главный инженер фирмы Cigital (Даллас, шт. Виргиния, www.cigital.com) и автор книги об интегрированной безопасности приложений "Software Security: Building Security In" (Addison-Wesley, 2006) г-н Мак-Гро делит программные ошибки на две основные категории. В первую он включает недостатки реализации, к которым относит такие классические слабые места, как возможность переполнения буфера, а во вторую - архитектурные бреши, не имеющие никакого отношения к отдельным строкам программы, поскольку они возникают в результате недостаточной проработки ее структуры.

Чтобы разобраться в проблеме, специалисты eWeek Labs встретились с ИТ-руководителями двух крупных и хорошо известных корпораций - MasterCard International со штаб-квартирой в г. Перчезе (шт. Нью-Йорк, www.mastercard.com) и Qualcomm (www.qualcomm.com) из калифорнийского города Сан-Диего. Главной темой состоявшихся обсуждений стали способы использования услуг сторонних компаний для организации безопасности программных приложений заказчика.

Не бойтесь перекладывать бремя защиты на соисполнителей

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

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

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

Cigital (www.cigital.com) основное внимание уделяет проверке качества ПО и оценке безопасности. Ее специалисты анализируют исходные тексты и архитектуру приложений с точки зрения их защищенности

Corsaire (www.corsaire.com/company) специализируется на безопасности информационных систем в Великобритании и Австралии.

Foundstone (www.foundstone.com) предлагает сервисы по обеспечению безопасности приложений, помогающие организациям создавать лучшее и более защищенное ПО. При этом, в частности, она использует опыт эксплуатации собственных средств безопасности.

Next Generation Security Software (www.ngssoftware.com) производит оценку уязвимости приложений и оказывает консультационные услуги по защите баз данных.

Compuware (www.compuware.com) разработала инструментарий DevPartner SecurityChecker 2.0, предназначенный для проверки приложений ASP и .Net. Эта компания также предлагает проведение проверок на основе своего инструментария непосредственно у клиента.

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

"У меня не возникает никаких проблем с тем, чтобы убедить руководство. Да и финансируются такие проекты вполне достаточно, - поясняет он. - Разработчики и производители тоже всегда готовы помочь. Но что нас ждет на выходе проекта? Создать безопасное приложение далеко не так просто, как может показаться на первый взгляд".

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

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

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

Со своей стороны Марк Мельберг, директор Coca-Cola (www.cocacola.com) по безопасности приложений, выступая на февральской конференции RSA в городе Сан-Диего (шт. Калифорния), указал на необходимость четко определять результирующие показатели безопасности. По его словам, фирма без малого полтора года назад начала создавать систему гарантирования безопасности своих разработок. "Прежде всего нужно было определить, насколько безопасны наши приложения, потому что именно это интересует руководство в первую очередь. Затем были сформулированы в понятной для руководства форме показатели, определяющие возможные риски. Без такой предварительной подготовки обращаться с просьбой о финансировании проекта разработки программного приложения бессмысленно", - сказал Мельберг.

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

Мак-Гро из компании

Cigital: “Главное -

сбалансировать

ресурсы и риски”

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

Учитывая все это, Терри Стэнли из MasterCard решил прибегнуть к помощи специалистов сторонней лаборатории, поручив им проверку безопасности всех компонентов - и аппаратных, и программных, задействованных по всему миру в процедурах аутентификации владельцев кредитных карточек корпорации. "Мы имеем дело с 23 тыс. банков, тысячами процессоров, 30-40 млн. торговых компаний, которые пользуются самыми разными платформами, - пояснил он. - Поэтому нам нужны специалисты, которые хорошо умеют проверять и оборудование, и программы".

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

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

Главное здесь - четко сбалансировать ресурсы и риски. А это, как отмечает г-н Мак-Гро из компании Cigital, задача не из легких: "Нужно найти такой путь, который, с одной стороны, позволяет заниматься разработкой кодов и при этом продолжать получать прибыль, а с другой - в полной мере учитывает сбалансированные требования безопасности. Все упирается в управление рисками".

Достичь в этом деле баланса г-н Роуз из компании Qualcomm надеется с помощью автоматизации: "Нужно усовершенствовать процесс разработки ПО и довести его до такого уровня, чтобы вопросы безопасности решались автоматически. Мы собираемся сделать это в ближайшие пару лет".

Сегодня уже имеется инструментарий проверки кодов, который помогает разработчикам решить проблемы безопасности, причем подобные средства зачастую предлагаются в виде внешних услуг. Фирма Compuware (www.compuware.com), например, предлагает своим клиентам произвести такое тестирование в течение двух дней, используя для этого приложение DevPartner SecurityChecker 2.0. Стоит такая услуга 6 тыс. долл., что вполне по карману даже небольшим компаниям с ограниченным бюджетом.

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

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

     Техническому директору eWeek Labs Камерону Стардеванту пишите по адресу: cameron_sturdevant@ziffdavis.com.