Очень часто в компаниях возникает задача оценки информационной безопасности по отношению к корпоративной сети. Это может быть частью аудита информационной безопасности, частью оценки проекта модернизации сети, частью аудита на соответствие стандартам безопасности. При этом желательно иметь некий рабочий план, по которому можно проводит аудит. Как подходить к проблеме создания такого плана?
Аудит корпоративной сети немного отличается от аудита информационных систем. Для аудита информационных систем на уровне операционной системы, СУБД или приложения можно воспользоваться рекомендациями и руководствами. Эти рекомендации и руководства предоставляются разработчиком соответствующего программного обеспечения или организаций, занимающихся созданием, разработкой, стандартизацией и распространением знаний в области аудита и контроля информационных систем (например, методологическими руководствами таких организаций, как www.isaca.org, www.isc2.org, www.owasp.org, и др.). Методологические руководства носят характер контрольного списка, по которому можно оценивать защищенность системы.
Корпоративная сеть является распределенной системой по самой своей сути, в этой системе нет единственной точки или устройства, защита которого позволила бы защитить корпоративную сеть целиком.
К тому же, целью атак на корпоративную сеть (за исключением атак типа отказ в обслуживании) являются чаще всего корпоративные сервера, пользователи, хранилища данных и т.д. Сама сеть рассматривается как промежуточное звено. Это усложняет определение того, какая часть корпоративной сети попадает в объем аудита, а какая нет. С корпоративными серверами проще. К примеру, мы определили систему SAP как критичную с точки зрения требований информационной безопасности, поскольку информация, которая обрабатывается в этой системе, является конфиденциальной. SAP состоит из двух серверов: сервера приложения и сервера баз данных. Оба сервера работают под управлением операционной системы AIX, на сервере баз данных используется СУБД Oracle. Соответственно эти сервера и попадают в объем процедур аудита.
Для аудита северов и инфраструктурного ПО мы можем получить программу аудита для соответствующих систем на сайте ISACA (доступно только для членов ассоциации) и использовать ее при аудите. Там же есть и программа для аудита сети. Эта программа, кроме вступительной части и части, охватывающей описание общего подхода, содержит два раздела: дизайн безопасной сети (Network Security Design) и компоненты безопасной сети (Network Security Components). Программа охватывает дискретную сущность (отдельные устройства) и интегрированную сущность (сеть в целом) корпоративной сети.
Но, к сожалению, в программе аудита сети, предложенной ISACA, выпущен важный момент – люди. А ведь именно люди и человеческий фактор иногда составляет одну из наибольших угроз. Например, в августе 2011 года неправильная конфигурация (как следствие недостатков процедуры управления конфигурациями) привели к значительному сбою в информационных системах Yandex.ru.
Повлиять на этот человеческий фактор можно, внедрив соответствующие процедуры и разделив обязанности. Например, рекомендуется внедрить управление изменениями в сети, процедуру управление конфигурациями, процедуру мониторинга доступности и производительности, процедуру управления инцидентами на уровне сети и т.д.
Аудит корпоративной сети немного отличается от аудита информационных систем. Для аудита информационных систем на уровне операционной системы, СУБД или приложения можно воспользоваться рекомендациями и руководствами. Эти рекомендации и руководства предоставляются разработчиком соответствующего программного обеспечения или организаций, занимающихся созданием, разработкой, стандартизацией и распространением знаний в области аудита и контроля информационных систем (например, методологическими руководствами таких организаций, как www.isaca.org, www.isc2.org, www.owasp.org, и др.). Методологические руководства носят характер контрольного списка, по которому можно оценивать защищенность системы.
Корпоративная сеть является распределенной системой по самой своей сути, в этой системе нет единственной точки или устройства, защита которого позволила бы защитить корпоративную сеть целиком.
К тому же, целью атак на корпоративную сеть (за исключением атак типа отказ в обслуживании) являются чаще всего корпоративные сервера, пользователи, хранилища данных и т.д. Сама сеть рассматривается как промежуточное звено. Это усложняет определение того, какая часть корпоративной сети попадает в объем аудита, а какая нет. С корпоративными серверами проще. К примеру, мы определили систему SAP как критичную с точки зрения требований информационной безопасности, поскольку информация, которая обрабатывается в этой системе, является конфиденциальной. SAP состоит из двух серверов: сервера приложения и сервера баз данных. Оба сервера работают под управлением операционной системы AIX, на сервере баз данных используется СУБД Oracle. Соответственно эти сервера и попадают в объем процедур аудита.
Для аудита северов и инфраструктурного ПО мы можем получить программу аудита для соответствующих систем на сайте ISACA (доступно только для членов ассоциации) и использовать ее при аудите. Там же есть и программа для аудита сети. Эта программа, кроме вступительной части и части, охватывающей описание общего подхода, содержит два раздела: дизайн безопасной сети (Network Security Design) и компоненты безопасной сети (Network Security Components). Программа охватывает дискретную сущность (отдельные устройства) и интегрированную сущность (сеть в целом) корпоративной сети.
Но, к сожалению, в программе аудита сети, предложенной ISACA, выпущен важный момент – люди. А ведь именно люди и человеческий фактор иногда составляет одну из наибольших угроз. Например, в августе 2011 года неправильная конфигурация (как следствие недостатков процедуры управления конфигурациями) привели к значительному сбою в информационных системах Yandex.ru.
Повлиять на этот человеческий фактор можно, внедрив соответствующие процедуры и разделив обязанности. Например, рекомендуется внедрить управление изменениями в сети, процедуру управление конфигурациями, процедуру мониторинга доступности и производительности, процедуру управления инцидентами на уровне сети и т.д.
