Программа обеспечения безопасности внутренних бизнес-приложений в корпорации Microsoft

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

сетевые стандарты и безопасность;
стандарты и безопасность компьютерных серверов;
стандарты и безопасность обработки данных в организации;
конфиденциальность информации.

О подразделении информационных технологий корпорации Microsoft

Организационная структура подразделения

На конец 2002 года в составе подразделения информационных технологий (Operations and Technology Group, OTG) корпорации Microsoft насчитывалось около 2,4 тыс. человек во всем мире, включая штатных работников, подрядчиков и стажеров, отвечающих за работу примерно 57 тыс. пользователей, более чем 150 тыс. настольных компьютеров и тысяч серверов, находящихся в более чем 400 точках в 62 странах.

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

Корпоративная культура

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

Такая концентрация служб в интрасети способствовала рационализации документооборота, однако одновременно она привела к созданию большого количества разнообразных приложений и баз данных, содержащих важные бизнес-данные, а также конфиденциальные сведения сотрудников. К концу 2002 года имелось уже свыше 1000 таких приложений и программных средств. Обеспечение их безопасности и было возложено на подразделение информационных технологий.

Задачи, решаемые подразделением

Подразделение информационных технологий выполняет две основные функции.

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

Процесс планирования в подразделении

Для реализации и эксплуатации был использован процесс, аналогичный программе MOF (Microsoft Operations Framework, www.microsoft.com/mof) и направленный на создание группы по разработке принципов и проведению оценки степени безопасности приложений, используемых внутри корпорации.

Программа MOF представляет собой набор советов, рекомендаций, общих принципов, примеров и моделей. В рамках MOF предоставляются стандарты по достижению необходимого уровня надежности, доступности, поддержки и управляемости ИТ-решений. Эти правила и рекомендации собраны с помощью специалистов консультационной службы Microsoft Consulting Services, подразделения информационных технологий корпорации Microsoft, сотрудников библиотеки инфраструктуры информационных технологий (Information Technology Infrastructure Library), а также бизнес-партнеров корпорации Microsoft.

Обоснование необходимого уровня безопасности приложений

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

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

Расходы на восстановление и потери продуктивности

В результате вторжения злоумышленника расходы на устранение повреждений, связанные как с вынужденным простоем, необходимым для восстановления поврежденных баз данных, так и с решением проблемы нарушения системы безопасности, а также ущерб от потери деловой репутации могут быть весьма значительными. Теоретически два дня простоя для интернет-торговца с годовым доходом в один млрд. долл. могут вылиться в миллионы долларов убытков в до-полнение к расходам на вос-становление (1 млрд. долл. дохода : 365 дней ґ 2 дня простоя = 5,5 млн. долл.).

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

Потери данных

Нарушения в системе безопасности могут повлечь за собой сбои в работе отдельных приложений и баз данных. Серьезное вторжение грозит полной потерей данных.

Снижение доверия клиентов

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

Опасность судебного преследования

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

Программа обеспечения безопасности приложений

Для того чтобы управлять процессами оценки и поддержания безопасности всех имеющихся и разрабатывающихся бизнес-приложений, подразделение информационных технологий сформировало группу, в которую вошли различные специалисты из нескольких отделов. Эти специалисты должны были обладать глубоким пониманием не только производственных требований корпорации Microsoft, но и вопросов безопасности информации. Результатом деятельности группы стала разработка программы обеспечения безопасности приложений (Application Security Assurance Program, ASAP), предназначенной для устранения потенциально уязвимых мест во внутренних бизнес-приложениях корпорации Microsoft путем приведения этих приложений в соответствие с принципами безопасности, выдвинутыми подразделением информационных технологий.

Принципы безопасности

Применение основных принципов безопасности на самых ранних этапах разработки жизненно важно для создания безопасных и надежных приложений. Корпорацией Microsoft была принята политика безопасности приложений, направленная на то, чтобы ее внутренние приложения всегда были безопасными. Основу этой политики составляют следующие принципы:

Конфиденциальность. Предотвращение раскрытия информации неуполномоченным лицам.
Целостность. Предотвращение повреждения, искажения или изменения информации или служб.
Проверка подлинности (аутентификация). Удостоверение личности или иного объекта в сети перед предоставлением этой личности или объекту доступа к данным.
Проверка полномочий (авторизация). Обеспечение доступа к данным только тем лицам, которые были надлежащим образом авторизованы и получили соответствующие права (на чтение, запись, изменение и т. д.).
Доступность. Обеспечение работоспособности и доступности информационных ресурсов, служб и оборудования.
Доказательство причастности. Установление связи между пользователем или объектом и действием. Это необходимо для того, чтобы доказать связь определенного действия с подозреваемым, отрицающим свою причастность.

Управление рисками

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

Подразделение информационных технологий одновременно применяет несколько методов снижения риска при внедрении новых внутренних приложений в корпоративную сеть Microsoft:

Стратегия

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

Тактика

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

Оперативные действия

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

Юридические аспекты

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

Создание программы обеспечения безопасности приложений

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

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

Программа ASAP включает несколько возможных контрольных точек в производственном цикле разработки программного обеспечения. На высшем уровне предусматриваются следующие контрольные точки:

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

Критерии оценки

Выполняя оценку уровня безопасности приложения, группа контроля учитывает целый ряд критериев.

Определение приложения

Прежде всего согласно программе ASAP необходимо определить, является ли конкретный программный продукт приложением¹. Изделия, не являющиеся приложениями, должны подчиняться правилам политики управления доменом подразделения информационных технологий. Если лицо, ответственное за внутренний программный продукт, может ответить «да» на все перечисленные ниже вопросы, считается, что продукт является приложением:

Поддерживает ли программное обеспечение бизнес-функции корпорации Microsoft (сюда включается все программное обеспечение – разработанное на заказ внутри корпорации Microsoft, приобретенное у сторонних разработчиков или услуги внешнего поставщика)?
Предоставляет ли программное обеспечение что-либо большее, чем простая статическая информация или данные? Например, сложнее ли оно, чем веб-узел SharePoint, простая веб-страница на языке HTML или статическая электронная таблица Microsoft Excel?

Границы оценки

Глубина исследования или оценки приложения определяются на основе анализа риска, связанного с его применением. Приложения имеют три уровня риска:

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

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

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

Всесторонние оценки включают все проверки процесса ограниченной оценки плюс исследование исходного кода приложения и используемых им данных.

В поиск уязвимых мест входят проверки веб-страниц, для посещения которых не требуется авторизация; сеансов, в которых не может быть предотвращено заимствование прав или атака с помощью воспроизведения файлов cookie; сообщений об ошибках, раскрывающих конфиденциальную информацию (например, имена серверов или пользователей); данных, которые содержатся в одном из каких-либо приложений и могут использоваться для вторжения в другое приложение.

Участники

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

Рис. 1. Отделы, задействованные в программе ASAP.

Структура процесса безопасности приложения

Общая задача программы ASAP определяется в структуре процесса обеспечения безопасности приложения, как показано на рис. 2.

Рис. 2. Структура процесса обеспечения безопасности приложения.

Соблюдение и публикация политики и инструкций

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

Процесс поддержки и публикации политики и инструкций проиллюстрирован на рис. 3.

Рис. 3. Процесс соблюдения и публикации политики и инструкций.

Повышение квалификации ИТ-специалистов

Отдел контроля приложений несет ответственность за то, чтобы имеющиеся знания по обеспечению безопасности приложений своевременно передавались всем категориям ИТ-специалистов корпорации Microsoft, включая разработчиков, испытателей и персонал поддержки. Обучение, предлагаемое внутренним и сторонним персоналом, соответствует роли сотрудника и предлагается на регулярной основе.

Проектирование, разработка, испытание и проверка безопасных приложений

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

Все приложения, для которых с точки зрения Microsoft необходима оценка угроз, проходят три отдельные проверки безопасности: одну – после проектирования, одну – после тестирования и еще одну – после развертывания в организации. В идеальном случае оценка должна выполняться еще до начала этапа проектирования, если уже известны технические детали, необходимые для ее выполнения. Это обеспечивает более точное планирование контроля проекта.

Проверка используемых в производстве приложений

Некоторые из имеющихся приложений подвергаются ограниченному послепроизводственному аудиту безопасности. Отделом корпоративной безопасности выполняется практическая оценка угроз, направленная на изучение уже известных или вновь обнаруженных уязвимых мест. Обычно такие оценки выполняются в основном для приложений с высоким риском. Программа ASAP предусматривает оценки следующих видов:

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

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

Реагирование на инциденты нарушения безопасности

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

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

Управление безопасностью приложений

В данном разделе описываются специфические элементы процесса обеспечения безопасности, играющие важную роль в программе ASAP.

Безопасная инфраструктура

Для безопасности приложений необходима безопасная инфрастуктура. Уязвимость на уровне сети и узлов может подорвать безопасность приложений и их данных. Инфраструктура разделяется на пять основных архитектурных компонентов:

сеть;
узел;
приложение;
учетная запись;
доверие.

Для каждой из этих областей характерны свои уязвимые места, которые необходимо отслеживать.

Чтобы минимизировать риск нарушения безопасности, необходимо реализовать детальную стратегию защиты среды, в которой выполняются приложения, от внутренних и внешних угроз. Данная стратегия, получившая название всесторонняя защита (defense in depth или security in depth), предполагает выстраивание уровней контрмер вокруг уязвимых областей. Она предусматривает внедрение мер защиты на каждом уровне инфраструктуры приложений, от внешних маршрутизаторов до места физического размещения ресурсов, включая все промежуточные пункты. Реализация нескольких уровней безопасности позволяет исключить зависимость приложений и ресурсов от отдельного сбоя.

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

Создание безопасных сетей для поддержки приложений

Первым шагом на пути защиты приложения является обеспечение безопасности сети, в которой оно выполняется.

Настройка сети

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

Топология сети организации должна быть проанализирована с точки зрения сетевой безопасности:

Сегментация сети минимизирует «неявные» доверительные отношения между серверами, нередко используемые при проведении атак.
Сегментация сети путем настройки виртуальной локальной сети позволяет разделить серверы в организации в соответствии с их ролями, а также уровнем важности хранящихся на них данных.

Для установки брандмауэров подразделение информационных технологий дает следующие рекомендации:

Брандмауэры должны максимально ограничивать число открытых портов для входящего и исходящего трафика – как для внутренних, так и для внешних сетей.
Необходимо регулярно проводить аудит конфигурации брандмауэра, чтобы предотвратить раскрытие дополнительных служб и серверов при обновлении параметров брандмауэра.
Для каждого брандмауэра должен применяться собственный пароль либо другой механизм контроля доступа. Это позволяет предотвратить применение одного и того же механизма для взлома нескольких брандмауэров.
Права на изменение функций, параметров подключения и служб, поддерживаемых брандмауэрами, должны принадлежать лишь нескольким доверенным и технически подготовленным сотрудникам, которым эти права необходимы для выполнения своих служебных обязанностей.
На серверах брандмауэров должны быть установлены и включены лишь самые необходимые компоненты операционной системы. Брандмауэр уровня приложений с функциями proxy-сервера, например Microsoft Internet Security and Acceleration (ISA) Server, является более эффективным решением, чем простой брандмауэр, выполняющий фильтрацию пакетов. Сервер ISA позволяет реализовывать дополнительные правила, допускающие использование только определенных коммуникационных запросов и протоколов.

Для настройки и эксплуатации маршрутизаторов и коммутаторов подразделение информационных технологий дает следующие рекомендации:

Пароль доступа к административному режиму (Enable Password) для маршрутизатора должен храниться в безопасном зашифрованном виде.
Только оператору сети и группам разработки, ответственным за создание, установку и настройку сетевых устройств, должно быть предоставлено право производить установку и удаление устройств, осуществлять техническую поддержку оборудования и изменять физическую конфигурацию маршрутизатора.
Маршрутизаторы должны регистрировать все изменения конфигурации с указанием времени, даты и сведений о пользователе, выполняющем изменения.
Журналы маршрутизатора должны направляться на узел журналов – выделенный компьютер в защищенной или доверенной сети, единственной функцией которого является хранение журналов.
Необходимо обезопасить узел журналов, удалив с него все ненужные службы и учетные записи.
Просмотр журналов для обнаружения признаков несанкционированного доступа должен выполняться регулярно. Данная обязанность должна лежать на группе операторов сети, ответственной за сопровождение маршрутизаторов.
Таблицы маршрутизаторов необходимо защитить от несанкционированного доступа и использовать только внутри организации. Изменение злоумышленником записей в этих таблицах может привести к снижению быстродействия, отказу служб связи и раскрытию важных данных.
Если в каких-либо службах, портах и протоколах нет явной потребности, они должны быть отключены.
Администрирование маршрутизатора должно осуществляться исключительно в локальной сети, а не в удаленном режиме (из глобальной сети или по коммутируемому соединению).

Системы распознавания сетевых атак

Мониторинг, направленный на обнаружение атак и событий системы безопасности, должен проводиться непрерывно и включать как пассивные, так и активные меры на уровне сети и приложений. Наиболее эффективной является реализация системы обнаружения атак внутри периметра безопасности, где отношение сигнал/помеха сравнительно невелико². Однако система обнаружения атак может быть полезна только в тех средах, где налажен процесс мониторинга и реагирования. Для реализации системы обнаружения сетевых атак можно использовать продукты сторонних производителей. Как минимум, такая система должна осуществлять мониторинг сети на наличие следующих трех атак:

атаки, проводимые в целях получения информации о системе;
атаки с использованием уязвимостей;
атаки типа «отказ в обслуживании».

Шифрование сетевого трафика

Шифрование – основное средство защиты секретных данных, позволяющее предотвратить чтение информации даже в тех случаях, когда пользователям удается получить к ней несанкционированный доступ. Секретные данные, передаваемые по внешним или внутренним каналам, должны шифроваться для обеспечения безопасности. Внешние каналы используются для обмена данными между клиентом и сервером, а внутренние – для обмена данными между серверами. Следует применять методы шифрования на основе отраслевых стандартов, например SSL (Secure Sockets Layer), оболочку обеспечения безопасности типа SSH или протокол IPSec (Internet Protocol Security).

Настройка безопасных узлов для приложений

Не менее важное значение для реализации безопасной сети имеет безопасность компьютеров, на которых выполняются приложения.

Работа с исправлениями

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

Настройка

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

Ненужные расширения файлов не следует назначать на веб-серверах, поскольку это может привести к атакам с применением неизвестных уязвимостей³.

Разрешения

Параметры ACL-разрешений⁴ должны быть правильно настроены для всех общих ресурсов и других элементов системы и баз данных, а также объектов COM+ в целях предотвращения несанкционированного доступа.

Общие строки протокола SNMP

Общие строки (community strings) протокола SNMP⁵ применяются для контроля доступа к объектам MIB⁶; они функционируют как встроенные пароли сетевого оборудования. К общим строкам SNMP применимы правила задания, хранения и периодической смены, используемые для надежных паролей. Если нет явной необходимости в использовании SNMP, следует удалить общую строку и отключить службу SNMP. Не следует забывать, что почти все устройства поставляются с используемым по умолчанию SNMP-паролем (public).

Антивирусные программы

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

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

Серверы: аудит и ведение журналов

Аудит и ведение журналов имеют важное значение для обнаружения атак и обеспечения целостности данных. Аудит

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

Архивация и восстановление сервера

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

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

Уровень приложений: требования

После обеспечения надлежащей защиты сети и хост-сервера необходимо позаботиться о безопасности самих приложений.

Проверка данных ввода

Проверка данных, вводимых пользователями, должна выполняться программным способом внутри кода приложения. Необходимо выполнять проверку использования специальных символов, числовых значений вне ожидаемого диапазона, длины строк, возможных вложений программного кода⁷, а также длины содержимого для загружаемых файлов. Более подробная информация о проверке данных ввода приводится далее в этой статье в разделе «Общие вопросы разработки приложений».

Управление сеансами

Коды сеансов⁸ должны быть произвольными и иметь достаточную длину для предотвращения взлома методом грубой силы. Информация о сеансах должна храниться на сервере, а не на клиентском компьютере. Если приложение хранит данные сеанса в виде простого текста в файлах cookie на клиентском ПК, злонамеренный пользователь сможет легко изменить данные сеанса и получить доступ к информации незаконным способом. Этот метод может быть также использован для получения разрешений более высокого уровня, например разрешения администратора. Сеансы должны закрываться по истечении времени ожидания после установленного периода бездействия или при выходе пользователя. Поскольку коды сеансов могут быть похищены и использованы повторно, не следует применять сеансы для кэширования данных проверки подлинности пользователя. Дополнительная информация о кодах сеансов и файлах cookie приводится далее в этой статье в разделе «Общие вопросы разработки приложений».

Проверка подлинности и авторизация

Некорректные методы проверки подлинности и авторизации могут стать причиной незаконного доступа к приложению. Приложение должно обеспечивать безопасное управление проверкой подлинности. Маркеры авторизации (authorization token) должны быть достаточно надежны, чтобы их нельзя было угадать, и должны надлежащим образом проверяться на сервере.

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

Проверка конструкции и программного кода приложения

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

Обработка ошибок на уровне сервера и приложения

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

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

Приложения: аудит и ведение журналов

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

Архивация и восстановление приложений

Рекомендации в разделе «Архивация и восстановление сервера» также относятся и к приложениям. Кроме того, необходимо архивировать весь исходный код приложений. Чтобы предотвратить незаконное раскрытие или использование не подлежащих разглашению данных, всю конфиденциальную информацию, записанную на архивных носителях (магнитных лентах, гибких и оптических дисках и т. д.) и хранящуюся вне организации, следует держать в зашифрованной форме.

Шифрование личных данных

Все личные данные (имена, пароли, сведения, позволяющие идентифицировать пользователя, информация о кредитных картах, даты рождения и т. д.) должны шифроваться с использованием надежного шифрования на основе отраслевых стандартов, например 3DES (Triple Data Encryption Standard). Информация этого типа не должна храниться в виде простого текста в каких-либо базах данных или файлах, независимо от того, насколько хорошо они защищены.

Общие вопросы разработки приложений

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

Выполняя оценку безопасности внутренних приложений, подразделение информационных технологий обычно получает представление о проблемах, относящихся к разработке.Заранее устранив выявленные таким образом проблемы, разработчики могут повысить безопасность своих продуктов и содержащихся в них данных.

Проверка данных пользовательского ввода

На основании опыта, полученного подразделением информационных технологий, проверка данных ввода поль-зователя должна выполняться во всех случаях, поскольку уровень риска уязвимости оценивается как высокий.

Следует считать входящие данные недействительными, пока не будет доказано обратное, даже если приложение предполагает, что все запросы действительны. Чем быстрее приложение распознает недопустимый запрос, тем меньше опасность ущерба от выполнения злонамеренного кода. Злоумышленники учитывают то, что медленное распознавание недопустимых запросов в системе влияет на обработку законных запросов, снижая производительность сервера. Это наиболее распространенный пример проведения атак с отказом в обслуживании.

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

Файлы cookie, проверка подлинности и доступ

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

Опыт, полученный подразделением информационных технологий, говорит о том, что шифрование файлов cookie должно быть обязательным во всех случаях. Файлы cookie никогда не должны применяться для хранения данных о привилегиях или разрешениях пользователей, поскольку это может привести к несанкционированному воспроизведению (replay attack) или неправомочному имитированию пользователя (unauthorized impersonation).

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

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

Использование простого текста в протоколе HTTP (Hypertext Transfer Protocol) позволяет злоумышленникам применять в локальной сети средства прослушивания для анализа и сбора секретной информации, включая файлы cookie и значения форм. Обычная проверка подлинности не защищает даже учетные данные пользователя (включая пароль).

Поскольку сценарии JavaScript и вспомогательные веб-файлы доступны всем пользователям, существует возможность раскрытия конструкции приложения. Клиентские сценарии всегда доступны пользователю, в то время как серверные вспомогательные веб-файлы обычно защищены от несанкционированного доступа.

Пароли

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

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

Таблицы управления доступом

Некорректная настройка таблиц управления доступом (ACL)⁹ может привести к тому, что пользователи получат непредназначенные для них разрешения для доступа к системным ресурсам и данным, в результате чего может быть раскрыта секретная информация, нарушена доступность или целостность системы. Всегда следует задавать минимальный уровень полномочий, необходимый для выполнения конкретной операции. Для предотвращения несанкционированного доступа следует правильно настраивать таблицы ACL для общих ресурсов и временных каталогов, создаваемых приложениями.

Настройка приложений COM+

Безопасность приложений COM+ может быть обеспечена с помощью встроенных служб, настраиваемых путем вызова программных интерфейсов из кода приложения или административным способом с помощью процесса, называемого «безопасностью на основе ролей» (role-based security).

Безопасность на основе ролей позволяет задавать параметры безопасности вплоть до уровней пользователя и метода; это означает, что с ее помощью можно определить, какие пользователи имеют права доступа к тем или иным ресурсам. Если для пользователя применяется роль, присвоенная запрашиваемому методу или ресурсу, то запрос будет выполнен успешно; в противном случае запрос выполнен не будет.

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

Аудит и ведение журналов

Политика подразделения информационных технологий требует исполнения разработчиками приложений правил аудита и ведения журналов.

Рекомендации и опыт

Усилия подразделения информационных технологий по инвентаризации, оценке и при необходимости устранении уязвимых мест, обнаруженных им в своих внутренних приложениях, оказались совсем не напрасны. В подразделении сформировалось более ясное представление о количестве и сложности приложений, использующихся для выполнения повседневных рабочих задач корпорации. Любое уязвимое место, обнаруженное в одном приложении, фиксировалось, после чего выполнялся его поиск в других приложениях. Возрос уровень безопасности не подлежащих разглашению бизнес-данных корпорации Microsoft и конфиденциальные сведения о ее сотрудниках. Формализация процесса оценки безопасности с помощью программы ASAP повысила уровень компетентности разработчиков в этой области, обеспечивая дальнейшее усиление безопасности будущих проектов.

В ходе этого процесса подразделение информационных технологий получило богатый опыт. В частности, им были выработаны следующие правила:

Если ждать, пока завершится разработка приложения, чтобы заняться его безопасностью, то можно опоздать. Уязвимые места уже проявятся.
Безопасность должна обеспечиваться всеми доступными средствами на сервере, однако при грамотном подходе к безопасности должно также учитываться и клиентское приложение.
Необходимо составлять четкие и легкодоступные документы с инструкциями по соблюдению безопасности.
Необходимо составлять контрольные списки по безопасности, которые должны включать пошаговые инструкции по обеспечению безопасности приложений, серверов и сетей.
Следует разработать тщательно продуманный процесс обработки исключительных ситуаций.
Повышение квалификации жизненно важно для достижения успеха программы обеспечения безопасности. Разработчики, испытатели и персонал поддержки должны время от времени проходить обучение, после которого их следует постоянно снабжать самой последней информацией, необходимой для обеспечения безопасности приложений.
Ведение инвентаризационной ведомости требует наличия соответствующих бизнес-процессов и отчетности. В рамках системы контроля безопасности следует проводить постоянное обновление следующей информации:
приложения и их версии;
статические IP-адреса по группам, владельцам и серверам;
список серверов (разработка, тестирование и производство) по приложениям;
политика и связанные инструкции;
исключения из политики и инструкций.
Обеспечение безопасности – это непрерывный, постоянно изменяющийся процесс. Для того чтобы текущие изменения распространялись на все приложения, необходима опытная группа специалистов по безопасности и тщательно проработанные бизнес-процессы.

Политика

Следующие принципы общей политики применяются ко всем приложениям, которые поддерживают выполнение производственных функций, независимо от того, разработаны они внутри организации или приобретены у сторонних поставщиков:

Все программные приложения, включая те, которые находятся в стадии разработки, должны отвечать требованиям политики безопасности приложений и инструкций.
Все новые, модифицированные приложения и приложения сторонних поставщиков должны пройти процесс контроля безопасности проекта и получить одобрение до того, как они будут развертываться в организации.
Для приложений сторонних разработчиков должно быть получено письменное заявление с гарантиями того, что программное обеспечение не содержит никаких скрытых механизмов, с помощью которых можно разрушить или обойти защитные элементы программного обеспечения.
В приложениях с выходом в интернет должны использоваться имеющиеся методы проверки подлинности. Не следует создавать новые процедуры проверки подлинности.
В приложениях, располагающихся в корпоративной сети, должны использоваться встроенные в Windows средства проверки подлинности.
В приложениях, в которых по объективным причинам или по причине ограничений кода устаревшего программного обеспечения невозможно использовать встроенные в Windows средства проверки подлинности, должно применяться шифрование или кэширование хранилищ паролей для предотвращения получения паролей в случае их кражи. При использовании шифрования ключи должны храниться в той же системе.
Не допускается хранение или пересылка учетных данных в незашифрованном виде. Например, номера кредитных карточек, номера телефонных карточек, пароли входа в сеть и идентификаторы ASP-сеансов, которые могут использоваться для получения доступа к товарам или услугам, всегда должны быть зашифрованы при хранении или пересылке.
Необходимо следить за тем, чтобы соблюдались законодательные требования, касающиеся конфиденциальности личных сведений.
Вся информация, вводимая пользователем, должна фильтроваться и проверяться на веб-сервере перед тем, как допускаться к обработке сценариями. Необходимо проверять соответствие размера и типа контента, чтобы предупреждать переполнение буфера и вставку кода.
В интернет-приложениях, обрабатывающих транзакции, должны использоваться строгие, непредсказуемые идентификаторы сеансов, защищенные от раскрытия.
В интернет-приложениях, обрабатывающих транзакции, должен быть реализован выход по истечении времени ожидания, чтобы сеанс пользователя был прерван после продолжительного периода бездействия.
Файлы cookie, содержащие такие конфиденциальные данные, как идентификаторы сеанса, должны быть помечены как защищенные и несохраняющиеся. При необходимости создания сохраняющегося файла cookie следует зашифровать его содержимое во избежание просмотра и искажения.

Обсуждение дополнительных вопросов безопасности

С выпуском Microsoft Windows Server 2003 появились новые средства и возможности, которые могут повысить безопасность внутренних приложений, за которые отвечает подразделение информационных технологий.

Диспетчер авторизации, новая функция в системе Microsoft Windows Server 2003, представляет собой централизованную интернет-службу выдачи разрешений на базе ролей, работающую со службой каталогов Active Directory. Этот компонент позволяет пользователям запрашивать, управлять, обновлять и аннулировать авторизацию приложений и веб-узлов. Служба выполняет проверку фактического доступа, используя данные из хранилища политик Active Directory. Централизованное управление доступом, обеспечиваемое диспетчером авторизации, уменьшает и административную нагрузку, и необходимость в ресурсах для управления правами пользователя. С его помощью уменьшается объем избыточной работы среди групп разработчиков разнотипных приложений, чем снижается потенциальная опасность появления новых уязвимых мест. Устраняется возможность упущений безопасности при обработке полномочий между приложениями. Пользователи получают в свое распоряжение функции самообслуживания при запросах доступа из отдельного стандартизованного приложения с соответствующим допуском, а для поддержания надлежащего административного контроля предусмотрен механизм уведомления.
Ограниченное делегирование – это метод обеспечения надлежащей проверки подлинности учетной записи, запрашивающей доступ, для нескольких защищенных серверов, соединенных в цепочку. Реализация ограниченного делегирования в системе Microsoft Windows Server 2003 позволяет использовать доверенные подключения к SQL-серверу, и учетные данные конечного пользователя могут пересылаться на компьютер, на котором работает SQL-сервер. Это также носит название «транзитное подключение» (hopping) сервера. Ограниченное делегирование является хорошим решением в ситуации, когда имеются ограниченные или специально определенные группы пользователей, которым могут быть предоставлены разрешения на доступ к SQL-серверу как через группу домена. Чтобы иметь возможность воспользоваться этой новой возможностью, все контроллеры доменов и серверы приложения IIS должны работать под управлением Microsoft Windows Server 2003.

По материалам информационного бюллетеня для государственных служб
«Современные подходы к обеспечению информационной безопасности.
Часть 2», который издает московскоепредставительство корпорации Microsoft
(рассылается бесплатно вместе с данным номером журнала).

Ссылки:

¹ Программное обеспечение, которое является ключевым компонентом существующего приложения (как, например, веб-служба, компонент COM+, служба Microsoft .NET, реплицированная база данных отчетности или пакетное задание), не рассматривается независимо от приложения, к которому этот компонент принадлежит.

² Нередко в системах обнаружения атак более 90% всех событий приходится на ложные срабатывания. Хотя журналы могут быть переполнены сообщениями о незначимых с точки зрения безопасности событиях, группы, отвечающие за безопасность, все-таки должны внимательно просматривать эти журналы для выявления реальных вторжений.

³ Атака с применением неизвестной уязвимости (zero-day exploit) – это атака, использующая обнаруженную злоумышленником уязвимость, о который или еще не известно производителю, или для устранения которой еще не было выпущено исправление.

⁴ ACL (Access Control List) – список контроля доступа. Используется сетевой операционной системой для определения прав доступа к общим сетевым ресурсам.

⁵SNMP (Simple Network Management Protocol) – простой протокол сетевого управления. Применяется для диагностирования работоспособности различных локальных вычислительных сетей.

⁶MIB (Management Information Base) – база управляющей информации. Корпоративная база данных, содержащая информацию о контролируемых и управляемых параметрах сетевых устройств.

⁷В л о ж е н и е п р о г р а м м н о г о к о д а (code injection) – технология, часто применяемая для получения незаконного доступа к данным или привилегиям. Изменение строки пользовательского ввода обычно выполняется путем добавления специальных символов и другого текста, распознаваемого обработчиками сценариев и базами данных и выполняемого ими в качестве сценария.

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