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

Как проектировать и писать безопасные программы?

19 июня 2013

Нет ничего непонятного в том, как проектировать и писать безопасные программы. Производители платформ разработки, языков программирования, независимые организации, вендоры ПО в области контроля качества ПО и просто крупные потребители труда программистов (например, Google) выпускают подробные руководства по безопасному программированию – от того, как обеспечить читаемость и переносимость кода, как описывать и именовать переменные, до того, как надо реализовывать конкретные функции. Но как, решив в один прекрасный день (обычно после крупного сбоя) внедрять у себя практику безопасной разработки ПО, начать это делать?

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

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

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

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

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