Операционная безопасность – технические составляющие и не только::БИТ 01.2014
 
                 
Поиск по сайту
 bit.samag.ru     Web
Рассылка Subscribe.ru
подписаться письмом
Вход в систему
 Запомнить меня
Регистрация
Забыли пароль?

Календарь мероприятий
ноябрь    2024
Пн
Вт
Ср
Чт
Пт
Сб
Вс
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

показать все 

Новости партнеров

14.11.2024

Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость

Читать далее 

14.11.2024

RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза

Читать далее 

14.11.2024

Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium

Читать далее 

14.11.2024

ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве

Читать далее 

08.11.2024

Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

Читать далее 

показать все 

Статьи

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

11.10.2024

Технологический ИИ-арсенал

Читать далее 

28.09.2024

Чем страшен ИИ, и с чем его едят

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

показать все 

Операционная безопасность – технические составляющие и не только

Главная / Архив номеров / 2014 / Выпуск №1 (34) / Операционная безопасность – технические составляющие и не только

Рубрика: Тема номера /  Технологии безопасности


Андрей Бирюковсистемный архитектор, ЗАО «НИП Информзащита»

Операционная безопасность –
технические составляющие и не только

Насколько хорошо работает служба ИБ в вашей организации? Поговорим об операционной безопасности

Операционная безопасность – неотъемлемая часть системы обеспечения информационной безопасности. Но насколько правильно организован этот вид защиты информации в каждой конкретной компании?

Немного теории

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

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

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

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

Не только техника

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

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

Это может привести к неприятным последствиям.

Рука руку моет

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

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

Еще один вариант не совсем правильной интеграции ИБ в корпоративную структуру – это включение данного отдела в департамент физической безопасности. Такая практика достаточно распространена в тех организациях, где заниматься информационной безопасностью стали сравнительно недавно, в то время как «физики» существуют давно.

Здесь возможны следующие риски. Охрана отвечает в том числе и за пропускной режим и внос-вынос материальных ценностей. И между ИБ и «физиками» возникают конфликты из-за неверно оформленных пропусков, попыток пронести оргтехнику.

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

Разделение обязанностей

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

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

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

Корпоративные политики – наше все

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

Когда незаменимых нет

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

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

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

В качестве рекомендации приведу типовые задачи, которые должны выполняться администратором безопасности, а не сетевым администратором:

  • Внедрение и сопровождение устройств и программного обеспечения безопасности.
  • Проведение оценки безопасности.
  • Создание и сопровождение профилей пользователей, внедрение и поддержка механизмов контроля доступа.
  • Настройка и сопровождение меток безопасности для среды мандатного управления доступом (MAC).
  • Установка первоначальных паролей для пользователей.
  • Анализ журналов регистрации событий.

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

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

Наименьшие привилегии и необходимые знания

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

И не следует забывать принцип наименьших привилегий. Сотруднику должен предоставляться минимальный доступ к корпоративным ресурсам, достаточным для работы. Необходимо на регулярной основе производить аудит прав доступа пользователей к системам. Для контроля разрешений в сетях под ОС Windows или UNIX можно воспользоваться продуктами компании Varonis DataAdvantage [2]. Данное средство поддерживает мониторинг прав пользователей в Windows, SharePoint, Exchange, UNIX/Linux. Принцип работы продукта прост: на целевую систему устанавливается агент, который в течение двух недель собирает начальную информацию о текущих разрешениях. Затем постоянно ведется сбор статистики, к каким ресурсам пользователи обращались. По результатам еженедельно выдается отчет, какие полномочия вообще не использовались, несмотря на наличие прав доступа.

Для контроля за настройками сетевого оборудования, в особенности за изменениями в списках доступа Access Control List, можно воспользоваться решением Tufin [3], который производит анализ настроек и выводит отчет об изменениях.

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

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

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

Операционная безопасность не только ИБ

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

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

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

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

Уровни отсечения

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

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

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

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

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

***

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

  1. CISSP All-in-One Exam Guide, 6th Edition Shon Harris.
  2. Решения по аудиту прав пользователей в Windows-системах – http://www.varonis.com.
  3. Мониторинг сетевых настроек Tufin – http://tufin.com.

В начало⇑

 

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи

Выпуск №06 (139) 2024г.
Выпуск №06 (139) 2024г. Выпуск №05 (138) 2024г. Выпуск №04 (137) 2024г. Выпуск №03 (136) 2024г. Выпуск №02 (135) 2024г. Выпуск №01 (134) 2024г.
Вакансии на сайте Jooble

БИТ рекомендует

           

Tel.: (499) 277-12-41  Fax: (499) 277-12-45  E-mail: sa@samag.ru

 

Copyright © Системный администратор

  Яндекс.Метрика