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

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

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

“По нашим наблюдениям, хакеры все чаще отказываются от попыток атаковать Windows и ищут более простые пути, — сказал Майкл Говард, главный менеджер ПО безопасности Microsoft и автор книги “The Security Development Lifecycle and Writing Secure Code” ("Жизненный цикл разработки защиты и создание безопасного кода"). — К сожалению, таких возможностей у них сейчас очень много”.

Иллюстрацией тому вполне может служить доклад “2008 Mid-Year Trend Statistics” ("Статистика тенденций в середине 2008 года"), подготовленный подразделением IBM Internet Security Systems X-Force. Исследователи этой организации констатируют, что бреши в веб-приложениях составляют 51% всех обнаруженных в текущем году уязвимостей: “За последние годы основной удар перенесен с операционных систем на веб-браузеры и мультимедийные приложения”.

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

Обучение программистов

Консорциум безопасности веб-приложений сообщил в июне, что серьезные бреши были найдены примерно в 97% из проверенных его специалистами 32 тыс. коммерческих веб-сайтов. Основную причину многие эксперты видят во все более слабой подготовке программистов типового ИТ-подразделения. “В мире работает 17 млн. программистов, но я сомневаюсь, что хотя бы 1% из них прошел официальную или неофициальную подготовку в области разработки безопасного ПО, — поделился своими мыслями Джеремия Гроссман, главный инженер и основатель фирмы WhiteHat Security. — В результате каждый день появляется множество кодов, написанных теми, кто имеет самое смутное представление о безопасной разработке ПО”.

А Говард считает, что даже выпускники университетских факультетов информатики получают дипломы, так и не научившись программировать с прицелом на безопасность создаваемых программ. “Это не обучение, а пародия на него, — сказал он. — Я знаю лишь несколько вузов, где будущим программистам дают базовые знания в том виде, как я их понимаю. Безопасность должна быть органически встроенной в приложения, а ее почему-то считают чем-то особенным, дополнительным. Но ведь защита является составной частью выпускаемого ПО!”

Изменение процессов

Основные трудности, с которыми сталкиваются организации, пытаясь предусматривать защиту в процессе разработки, связаны с тем, что безопасность невозможно обеспечить в один прием, добавить в виде отдельной функции. Этот аспект должен быть встроен в полный цикл программирования. “Безопасность — понятие комплексное, а это значит, что на сборочном конвейере нет пункта, где кто-то прикрутит ее на место, — предупреждает Брайен Чесс, научный руководитель фирмы Fortify Security, производящей инструментарий анализа кодов. — Путь к надежной защите приложения пролегает через множество направлений и массу процессов”.

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

По мнению Говарда, единственный способ добиться от программистов безопасных кодов состоит в том, чтобы сделать такой подход приоритетным в верхах организации, а затем постепенно продвигать его вниз. К такому выводу он пришел на собственном опыте, отвечая за разработку жизненного цикла безопасности (SDL) внутри собственной корпорации, а затем распространяя его по всем подразделениям. Основу этого подхода составляют три принципа: никогда не доверять информации на входе, использовать fuzz-тестирование и моделировать угрозы. Внедрение этих принципов, как предупреждает Говард, может длиться годами и вначале требует всемерной поддержки разработчиков, однако по мере того, как такая практика входит в повседневную жизнь, ситуация меняется. “В один прекрасный момент люди как будто просыпаются, — замечает он, — и начинают понимать, что безопасность — неотъемлемая часть их работы, что-то такое, что просто невозможно не делать. После этого руководству уже не приходится постоянно следить, чтобы группа разработки уделяла внимание защите”.

Microsoft настолько поверила в действенность SDL, что начальник Говарда, старший директор по стратегии в области безопасного инжиниринга Стив Липнер, и остальные члены команды SDL недавно решили сделать свой внутренний инструментарий моделирований угроз доступным для всей отрасли.

Преимущества для бизнеса

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

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

Еще важнее, впрочем, то, что организация может больше не бояться потенциальных потерь в миллионы долларов из-за уязвимости своих приложений. По словам Говарда, чтобы помочь своему коллеге из другой компании обосновать выделение дополнительных 200 тыс. долл. на безопасное кодирование, он просто зашел в отдел управления рисками и попросил оценить информацию, на защиту которой пойдут эти деньги. Мнение руководства, которое прежде выступало против таких затрат, резко изменилось, когда оказалось, что под угрозой находятся ресурсы компании стоимостью 30 млн. долл. В результате, как только презентация закончилась, Говарду задали один-единственный вопрос: “Что нужно подписать?”

Медленная реализация

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

Претворение планов руководства в жизнь требует времени. “Ничто не меняется в одночасье, — предупреждает Грег Ханчин, руководитель фирмы-реселлера DirecSec, которая специализируется в области безопасности. — Едва ли кому удастся сходу наладить безопасное кодирование приложений. Но можно сделать по-другому: попытаться внести в круговерть людей, процессов и технологий свежую техническую струю, а затем сплачивать вокруг нее сотрудников и процессы, постепенно улучшая тем самым создаваемое ПО. Но заметных изменений в процессе разработки придется подождать пару лет”.

Пока же этого не произошло, организации могут воспользоваться некоторыми другими приемами. “Я бы начал с освоения современных инфраструктур разработки, — советует Гроссман. — Ведь многие из них, включая .NET и J2EE , обеспечивают высокую безопасность сами по себе. При правильном их применении можно не только очень быстро создавать коды, но делать их защищенными”.

Сертификация

“Слишком уж часто безопасность пытаются обеспечить в конце жизненного цикла приложения, реагируя только на обнаруженные уязвимости, а то и вообще после взлома, — предупреждает Говард Шмидт, президент Information Security Forum и член совета директоров некоммерческой фирмы (ISC)2, которая занимается обучением и сертификацией специалистов по ИБ. — Каждый день появляются все новые приложения без каких-либо базовых средств защиты и напрочь игнорируются тысячи существующих уязвимостей”.

(ISC)2 полна решимости изменить такое положение вещей. Совсем недавно, скажем, она анонсировала новый сертификат CSSLP (Certified Secure Software Lifecycle Professional — сертифицированный специалист по жизненному циклу безопасного ПО), призванный “поддерживать практику и опыт разработки безопасного программного обеспечения”. Это сделано с целью распространения передового опыта и развития профессионализма при решении проблем защиты ПО на протяжении всего жизненного цикла.

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

“CSSLP вооружает людей, причем именно тех, кто составляет нашу первую линию обороны в войне с хакерами, инструментарием и умением его применять, обеспечивать безопасность на протяжении всего жизненного цикла ПО”, — констатирует исполнительный директор (ISC)2 У. Хорд Типтон.