В последнее время сдвинулся с мертвой точки такой непростой вопрос, как установка требований по безопасности не только для разработчиков средств защиты, но и для разработчиков прикладных систем, в частности систем ДБО. Об этом активно говорили на Магнитогорской конференции, называя низкую защищенность систем ДБО одной из ключевых причин хищений средств со счетов клиентов. В России сейчас формируются такие требования, которые установят для разработчиков ДБО единые правила, которые надо будет соблюдать для работы на рынке.
Но Россия тут не пионер. Одним из первых к этой теме обратился PCI SSC, который выработал определенные требования к разработке платежных приложений - стандарт PA DSS . Правда, подпадают под него далеко не все приложения , которые обрабатывают финансовые потоки. В т.ч. под него спокойно могут не попасть многие системы ДБО, особенно для юридических лиц, т.к. они не обрабатывают данные платежных карт. Но как основа для формирования собственных требований данный стандарт подходит достаочно неплохо.
Еще один интересный документ был опубликован совсем недавно - в январе этого года. Речь идет о Software Assurance Framework от BITS - подразделения по разработке технологических политик Financial Services Roundtable. Этот 53-хстраничный документ, который описывает целую программу защищенной разработки ПО для финансовых институтов. 8 частей этого документа охватывают все необходимые темы при разработке защищенных приложений:
В качестве заключения хочу отметить, что разработчикам приложений (и не только финансовых) пора уже больше внимания уделять правилам защищенной разработки программного обеспечения. А клиентам могу посоветовать быть более требовательными при общении с разработчиками.
Но Россия тут не пионер. Одним из первых к этой теме обратился PCI SSC, который выработал определенные требования к разработке платежных приложений - стандарт PA DSS . Правда, подпадают под него далеко не все приложения , которые обрабатывают финансовые потоки. В т.ч. под него спокойно могут не попасть многие системы ДБО, особенно для юридических лиц, т.к. они не обрабатывают данные платежных карт. Но как основа для формирования собственных требований данный стандарт подходит достаочно неплохо.
Еще один интересный документ был опубликован совсем недавно - в январе этого года. Речь идет о Software Assurance Framework от BITS - подразделения по разработке технологических политик Financial Services Roundtable. Этот 53-хстраничный документ, который описывает целую программу защищенной разработки ПО для финансовых институтов. 8 частей этого документа охватывают все необходимые темы при разработке защищенных приложений:
- Обучение и тренинги разработчиков
- SDLC. Тема SDLC становится достаточно популярной в последнее время. И я про нее писал в блоге и в отдельной статье в "ИТ Менеджере". Эта же тема освещается и на специализированной конференции в России - SECR .
- Моделирование угроз. BITS упоминает Microsoft STRIDE, хотя таких стандартов и рекомендаций существует десятки (я их рассматриваю в курсе по моделированию угроз). И писал про это недавно.
- Лучшие практики программирования. Интересно, что BITS не выдумывает ничего своего, а отсылает к уже существующим практикам - OWASP Secure Coding Practices Guide, Department of Homeland Security Build Security In Portal, CERT Secure Coding, MSDN Security Developer Center и т.д.
- Тестирование безопасности. Этот кусок очень неплохо расписан - упомянуты различные программные продукты, виды анализа кода и т.д.
- Практика предварительного внедрения
- Документирование. Раздел подробно описывает, какие документы должны сопровождать разработку и тестирование программного обеспечения.
- Контроль пост-внедрения.
В качестве заключения хочу отметить, что разработчикам приложений (и не только финансовых) пора уже больше внимания уделять правилам защищенной разработки программного обеспечения. А клиентам могу посоветовать быть более требовательными при общении с разработчиками.
