• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Почему бы компаниям не писать безопасные приложения?

05 июня 2013

Специалисты по информационной безопасности кричат в один голос – внедрение цикла безопасной разработки бизнес-приложений может серьезно сократить проблемы с киберпреступностью. Всем понятно, что если проблему безопасности разработок начать решать еще во время проектирования, то ресурсов на поддержку и ликвидацию последствий инцидентов придется тратить в десятки раз меньше (по данным HP - в 30 раз). Все соглашаются, но никто ничего не делает. Почему?

Постановка процесса безопасной разработки (SDL, или SDLC – Security Development Lifecycle) - хорошо описанный процесс, отработанный разработчиками тиражных продуктов и крупными интернет-компаниями. Как его внедрять - описано в отличных руководствах и «лучших практиках» для всех стилей программирования: от «классического» до «экстремального». Все рекомендации известны. Берешь и делаешь «раз», делаешь «два», делаешь «три». Как делать – понятно, где сделано – можно посмотреть. Непонятно только одно – зачем делать.

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

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

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

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

Что cподвигнет компании разрабатывать безопасный заказной бизнес-софт? Пока мотива нет даже на горизонте. Даже банковское сообщество, больше других отраслей страдающее от уязвимостей финансовых приложений и получающее прямые убытки от хищений денег, только-только делает первые робкие шаги в этом направлении. Что же говорить о безопасной разработке государственных систем, ERP-систем и систем документооборота? На наш век программистских «косяков» хватит.

Оставить свой комментарий:

Комментарии по материалу