:::::: ЧОУ ДПО «Центр предпринимательских рисков» :::::

Информационная безопасность в жизни информационных систем

Старший консультант отдела анализа и контроля рисков, PwC

Консультант отдела анализа и контроля рисков, PwC

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

Ущерб от реализации рисков ИБ, связанных с управлением ЖЦ ИС, может в несколько раз превышать стоимость внедрения защитных мер, и совершенно очевидно, что эти риски необходимо снижать. В данной статье проводится обзор основных угроз ИБ, связанных с управлением ЖЦ ИС, и предлагаются рекомендации по их нейтрализации.

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

Существуют различные типы моделей ЖЦ ИС, и разные компании могут использовать наиболее удобные для себя подходы. Наиболее распространенная модель представлена на рисунке.

Каждая из приведенных стадий несет в себе определенный набор угроз И Б, которые должны быть своевременно учтены и обработаны. Наиболее распространенные угрозы ИБ:

неверная формулировка требований к ИС;
неадекватный выбор процессов ЖЦ и вовлеченных в них участников;
принятие неверных проектных решений;
внесение разработчиком дефектов на уровне архитектурных решений;
внесение разработчиком недокументированных возможностей в ИС в целом или в ее отдельные компоненты;
неадекватная (неполная, противоречивая и пр.) реализация предъявленных к ИС требований;
сборка ИС с нарушением предъявляемых требований, приводящая к появлению недокументированных возможностей в ИС либо к неадекватной реализации требований;
разработка некачественной документации;
неверное конфигурирование ИС;
приемка ИС, не отвечающей требованиям, установленным в компании;
внесение недокументированных возможностей в ИС в процессе проведения приемочных испытаний посредством использования недокументированных возможностей функциональных тестов и тестов ИБ.

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

На стадии инициации, или концепции ИС, определяются цели, задачи использования ИС и ее основные функции, осуществляется выбор поставщика (разработчика) ИС, определяются методы и средства разработки. Для обработки угроз ИБ на стадии инициации рекомендуется выполнить следующие мероприятия:

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

2. Определить источники требований безопасности. Основными источниками требований ИБ, предъявляемых к ИС, являются:

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

Например, если целью разработки ИС является обработка ПДн, то целесообразно уже на данном этапе определить, какие защитные меры должны использоваться, опираясь на требования законодательства.

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

4. Определить контроль безопасности для каждой стадии. Документирование процедур тестирования функций безопасности в формате матрицы позволяет разработчикам и специалистам ИБ анализировать разработку и внедрение компонентов системы и помогает облегчить анализ рисков и обнаруженных проблем безопасности.

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

Наиболее распространенными угрозами ИБ, присущими выбранной модели, являются:

неверная формулировка требований к ИС
неадекватный выбор процессов ЖЦ и вовлеченных в них участников;
принятие неверных проектных решений;
внесение разработчиком дефектов на уровне архитектурных решений;
внесение разработчиком недокументированных возможностей в ИС в целом или в ее отдельные компоненты
неадекватная (неполная противоречивая и пр.) реализация предъявленных к ИС требований;
сборка ИС с нарушением предъявляемых требований приводящая к появлению недокументированных возможностей в ИС либо к неадекватной реализации требований;
разработка некачественной документации;
неверное конфигурирование ИС
приемка ИС, не отвечающей требованиям, установленным в компании;
внесение недокументированных возможностей в ИС в процессе проведения приемочных испытаний посредством использования недокументированных возможностей функциональных тестов и тестов ИБ

Безопасность при разработке ИС может быть обеспечена следующими мерами:

1. Определение процедур разработки ИС. С целью снижения вероятности возникновения проблем с безопасностью заранее должны быть определены методы и средства разработки. Они должны охватывать все используемые языки программирования (C++, JavaScript, SQL и пр.).

2. Организация среды разработки. Для организации безопасного процесса разработки рекомендуется выделить рабочие места ответственных лиц в отдельный защищенный сетевой сегмент, обеспечить рабочие места средствами антивирусной безопасности и защиты от НСД, использовать "чистую" лицензионную политику. Эти простые меры позволят значительно снизить риски несанкционированного доступа и изменения кода посторонними лицами.

3. Обучение персонала методам безопасной разработки. Понимание проблем безопасности современных приложений и новых способов атак крайне необходимо для создания защищенной ИС, поэтому проведение тренингов по ИБ для разработчиков может существенно повысить качество и безопасность ИС.

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

5. Разработка (получение) документации на ИС. Документация на ИС должна включать описание применяемых защитных мер и функций, описанных в техническом задании. С точки зрения ИБ документация как минимум должна содержать:

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

На стадии внедрения и оценки ИС проводятся работы по ее непосредственному монтажу и тестированию функций, в том числе функций ИБ.

Рассмотрим основные мероприятия по обеспечению ИБ для стадии внедрения и оценки ИС.

1. Разработка плана внедрения и оценки ИС. План является ключевым документом, определяющим все действия по внедрению ИС в инфраструктуру компании. С точки зрения ИБ план должен определять перечень защитных мер ИС и объем их тестирования.

2. Проверка документации на ИС. Вся документация должна быть на финальной стадии к моменту проверки и должна содержать описание всех требований ИБ, предъявляемых к ней техническим заданием.

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

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

5. Внедрение ИС и настройка функций защиты. После завершения всех тестов и проверок выполняются работы по монтажу ИС и настройке функций защиты. Ответственные за ИБ должны провести проверку соответствия настроек защитных мер, предъявляемым требованиям ИБ.

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

1. Оценка влияния вносимых изменений на состояние ИС. Каждое изменение, будь то внедрение нового модуля, добавление нескольких полей данных или установка обновлений ОС на сервере ИС, должно анализироваться на предмет влияния на состояние защищенности ИС. Процедуры контроля изменений должны предусматривать порядок уведомления лиц, ответственных за И Б, об изменениях ИС, а также порядок анализа изменений, их утверждении и документировании.

Например, рекомендуется проводить анализ, учитывая следующие аспекты:

влияние на производительность и защищенность ИС;
тип изменения (корректировка, модернизация, профилактика или адаптация к новым условиям);
объем (размер изменений, стоимости, времени на реализацию изменения).

2. Контроль параметров безопасности ИС. Рекомендуется разработать план проверок ИС на соответствие предъявляемым требованиям ИБ. Контроль должен включать проверку корректности настроек и работоспособности защитных функций ИС. Дополнительно пользователями и администраторами ИС должен осуществляться постоянный мониторинг работоспособности защитных функций. После каждого внесения изменения в ИС или в ее среду функционирования должен проводиться контроль настроек функций безопасности.

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

Регуляторы и правительство, в свою очередь, также понимают важность данной области ИБ и работают над решением проблем, разрабатывая новые рекомендации и требования. В качестве примера можно привести Банк России, заявивший на последней межбанковской конференции о разработке новых рекомендаций в области стандартизации "Требования к банковским приложениям и разработчикам банковских приложений".
Сейчас можно сказать одно - проблема получила толчок, сообщество ИБ обеспокоено сложившейся ситуацией и предпринимает действия по ее решению. Будем надеяться, что в скором времени в нашем арсенале появятся новые инструменты для эффективной обработки рисков ИБ, связанных с управлением ЖЦ ИС.

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

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

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

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

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

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