Было бы очень занимательно поуправлять ЦРУ, но это доступно только товарищу Сноудену. В данной заметке (хотя размер для заметки великоват) речь пойдет про три столпа ИБ, как уже все, конечно, догадались: конфиденциальность (Confidentiality), целостность (Integrity), доступность (Availability). Материал не сильно похож на тот, что есть в учебниках российского производства, поэтому, надеюсь, будет интересным. Некоторые понятия оставляю в оригинале, те, кто в курсе в переводе не нуждаются, да и в контексте, думаю, будет все предельно ясно. Каждый из этих трех аспектов тесно связан физической безопасностью (Safety) и нарушение какого-либо из них может привести к негативным последствиям.
Рассмотрим популярные сегодня облачные сервисы, основными преимуществами которых являются scalability and flexibility or elasticity. Доверяя свои данные другой организации, к примеру, SP (service provider), нужно быть уверенным, что они останутся известными только нам, т.е. обеспечить их конфиденциальность (С). Какие основные средства (control types) можно использовать? В независимости от платформы мы можем применять… криптографию или шифрование, кому как больше нравится.
- File by file encryption – прежде чем отправлять критичную информацию за «периметр», в независимости от предоставляемых услуг (ха, да ладно, SP шифрует у себя в облаке), необходимо предварительно локально шифровать всю информацию. Аналогично, если информация хранится на мобильных устройствах – full device/disk encryption, как обязательное условие использования.
- Следующее условие – разграничение доступа к ресурсам (Access control), Information separation, в разрезе Technical controls, дальше будет понятно почему. Основная схема применения – это MAC-DAC (не путать сами знаете с чем) и RBAC. Используя эти схемы мы можем обезопасить себя от неавторизованного доступа к информации.
- Ну и немного игрушечное, но также эффективное средство – стеганография. Тем, кто не знаком — OpenPaff в помощь. Можно попробовать обойти DLP =), обеспечив конфиденциальность передачи sensitive information в обход политики безопасности.
Являясь администратором критически важных компонентов инфраструктуры, нередко приходится их обновлять. Как быть уверенным, что обновления являются именно оригинальными файлами от разработчика, т.е. их целостность (I) не нарушена. Специально для этих целей на сайтах разработчиков рядом со ссылкой на объект, обычно есть строка с дополнительной идентифицирующей информацией – checksum или HASH. Это одностороннее вычисление контрольного значения на основе HASH функции (MD5, SHA-1). И эти значения должны совпадать – на сайте и ваше, вычисленное после скачивания.
Следующая технология обеспечения I сполна использует описанную выше – это электронные подписи (согласно ФЗ №63), или электронные цифровые подписи, как их называли раньше. Существует 3 вида ЭП: простая и усиленные: квалифицированная, неквалифицированная. В зависимости от вида, ЭП обеспечивает «неотказуемость» автора (non-repudiation) и/или целостность отправленного сообщения. Вся суть использования ЭП сводится к технологии ассиметричного шифрования – отрытого и единственного парного к нему закрытого ключей. Для глобального применения ЭП специально формируется инфраструктура открытых ключей (PKI), основным структурным элементом которой является УЦ (CA), где все субъекты ЭП верят УЦ.
Теперь немного о доступности (availability). У нас есть много денег, сделаем redundancy (избыточную) инфраструктуру. Какая выгода? High availability – clustering – fault tolerance. При форс мажоре можно быть уверенным, что системы будут доступны, а при отсутствии негативных факторов, можно увеличить быстродействие. Немаловажный фактор A – это грамотная установка патчей (patching). Прежде чем что-то обновлять нужно все тщательно протестировать и согласовывать все изменения документационно (change management).
Применяя меры организационной и технической безопасности, нельзя забывать про физический доступ. При возможности, а что-то и в обязательном порядке, использовать ограждения, видеонаблюдение, специальные замки и т.п.
«Делай деньги, делай деньги, а остальное все дребебедень…»
Итак! Никто не хочет терять «нажитое непосильным трудом» — Активы. Ущерб от возможных негативных последствий всегда есть — Угрозы. Непробиваемых систем не бывает – Уязвимости. А вероятность ущерба от эксплуатации уязвимости – это Риск. Если нарушение CIA – это угроза, то необходимо каким-то образом этой угрозе противодействовать (risk mitigation — countermeasures).
Каждому админу знакомы и близки, так называемые Technical controls. Это все технологии, которые применяются для обеспечения ИБ: FW, Port Security, ACL, AV, IPS, UTM, DLP, PKI, 802.1x, Passwords и т.п. В принципе, что еще нужно то? =)
Нужно то, на основе чего все это должно функционировать: Management controls – административное управление. Очень грамотный Risk/Vulnerability assessment как основа для политики безопасности, утвержденной руководителем организации, а также иные нормативные документы, регламентирующие деятельность организации в области ИБ – все это административное управление.
На основе менеджмента строится оперативный или операционный контроль – ежедневные регламенты по работе, инструкции, планы очередныхвнеочередных работ (change management). Все это должно коррелировать с политикой безопасности с целью определения «нормального» функционирования ИТ инфраструктуры.
О важности политик (management controls) «Все, что оговорено – рекомендуется, все, что написано – исполняется!»
Для простых пользователей рекомендуется делать что-то наподобие выжимки политики (privacy policy, acceptable use policy), акцентировав внимание именно на том, что пользователь может или не может, т.е. определить сферы его влияния и ответственности (работа с почтой, интернет, съемные носители, разглашение КТ и т.п.), обязывать пользователя не выключать серверное оборудование во время рабочего дня смысла нет, т.к. он не должен иметь доступа к этой зоне ответственности. Эти политики могут пересматриваться так часто, как это необходимо с точки зрения должностных обязанностей.
Глобальная политика безопасности (security policy) – основывается на сфере в которой организация функционирует и состоит из множества страниц текста, диаграмм и т.п., описывая всевозможные ситуации. В идеале в этой политике можно найти ответ на любые вопросы по информационной безопасности в организации.
В политике или иных документах стоит отразить следующие процедуры уменьшения риска, связанные с субъективной составляющей.
- Mandatory vacations: (сложно поверить), в этот период сотруднику запрещено появляться на работе и контактировать с сотрудниками компании, чтобы уменьшить или выявить мошенничество (fraud, embezzlement, neglect) — Discovering or deterrent mechanism. К примеру, SuperAdmin ушел в обязательный отпуск, на его место направили другого skilled person для выявления нарушений политики SuperAdmin-ом. Обычно действенно в финансовых учреждениях. По опыту работы в банке, могу сказать, что все описанное верно, но только в Planned vacations, ни разу mandatory не встречал. По идее, это должно помогать при увольнении сотрудника, чтобы в организации всегда была бы наготове его подмена (cross-training).
- Примерно тоже самое, только без обязательного отпуска (как раз что и есть в большинстве организации) – Job rotation.
- Один из самых главных способов контроля – разграничение обязанностей, принцип 2-х персон и т.п. (Separation of Duties). Критичная операция, состоящая из нескольких итераций не может исполняться одним субъектом – каждый субъект контролирует свою зону ответственности.
- Сразу же вытекает еще один немаловажный фактор – минимальные привилегии (права) для выполнения обязанностей или принцип необходимости и достаточности (Least privileges). К примеру, у вас (сетевика) есть допуск к сведениям, имеющим гриф ДСП, этого достаточно чтобы иметь доступ к любым документам ДСП, но есть ли необходимость доступа к документам, например, по датчикам физической защищенности, они тоже ДСП? Ответ, нет! Эта информация не в вашей сфере ответственности. Поэтому сначала делятся права (по минимальному принципу), а уже потом назначается ответственность.
Основным в политике, при таких изменениях в ролях и ответственности, должна стать процедура проведения периодического аудита, с целью выявления возможных пересекающихся «коллизий прав доступа», когда один субъект получает права всех субъектов, за которых он когда-то выполнял обязанности, не говоря о других проблемах ИБ.
Риски при интеграции со сторонними организациями.
«Пиши больше бумаг — больше бумаг меньше проблем». В принципе больше и сказать нечего: SLA – service layer agreement, BPA – business partner agreement, MOU – memorandum of understanding, ISA – interconnect security agreement.
В общем, как и везде, описать наиподробнейшим способом процедуры взаимодействия и ответственность сторон за разглашение, хранение, обработку и т.п. Мало ли, в суд придется идти…
Мы считали, мы писали
Теперь возьмемся за счеты. Сколько нужно потратить, чтобы уменьшить риск – quantitative risk analysis (количественный анализ).
Например, у нас есть актив – сервер, стоимостью 1100, нам предлагают страховку – 250 в год, перенос риска на страховую компанию (risk transference). Сначала определим SLE (single loss) – стоимость однократной замены = 1100. ARO – annual rate occurrence – как часто в год происходит поломка (1 раз в 5 лет) = 0.2. ALE – annual loss expect (потеря в год) = SLE * ARO = 220, это меньше чем страховка на год. Делаем правильный выбор.
Кроме переноса риска, мы можем его избегать (avoidance – not allow BYOD), принимать (accept — cheaper), уменьшать (mitigation — FW, AV), противодействовать (deterrence — mantrap). Также существует качественный анализ риска, на основе экспертных оценок (qualitative): Impact * Likelihood, не очень точный вид анализа, но лучше, чем ничего.
Для оценки надежности функционирования введены следующие понятия:
- MTBF – meantime between failure — сколько часов проработало между отказами, надежность.
- MTTR – meantime to restore – время необходимое для восстановления, скорость.
- MTTF – meantime to failure – сколько проработало до отказа, после развертывания.
- Threat vector – та технология, которую будут атаковать (email, web, IM, Tel).
- RTO – recovery time objective — за сколько времени восстановим.
- RPO – recovery point objective – на сколько давнюю версию копии использовать.
Как уменьшить риск?
Ответ на поверхности: либо избавиться от уязвимостей, либо от угроз. Весьма вероятно, что от угрозы избавиться не получится. Поэтому все и пытаются закрыть известные уязвимости. Про 0-day vunls сейчас не говорим. Закрываются уязвимости в основном через technical controls, применение которых должно быть описано через change management. План проводимых работ (тест, мониторинг, восстановление) с подробнейшим описанием действий и временными интервалами с указанием ответственных лиц, должен быть подписан всеми заинтересованными сторонами. Также необходим план восстановления при форс мажорных ситуациях. «No security issues after update».
Грустная часть. Incident management – что-то плохое произошло, и мы не успели противодействовать. Наши действия должны совпадать с планом, заранее подготовленным на такие случаи. Пользователи должны действовать согласно инструкции или политике (кому звонить, писать или бросать все и бежать), а для этого их нужно учить – Security awareness. Готовить план после инцидента – бессмысленно.
Про аудит прав пользователей уже говорили – это очень важно, а то может получится, что «вахтерша т. Маша», откроет хранилище и резко перестанет быть вахтершей. Уволенных сотрудников отключать (когда уверены в их ненадобности удалять), отпускников не пускать. Проводить аудиты, как запланированные, так и внезапные – в результате должен получаться отчет о проведенном аудите. Такие отчеты должны анализироваться с целью определения динамики и, возможно, воздействия на сотрудников.
Во многих организациях обрабатывается Pii, по-русски ПДн. Про законодательство РФ ни слова =). Данные должны быть в закрытом виде (зашифрованы), для защиты от утечек можно внедрить DLP (с зашифрованными данными не поможет, но не забываем про разбор SSL), запретить использование съемных носителей с помощью софта, политик, скриптов.
Если инцидент произошел, то нужно расследовать – Forensics.
Три основных шага при non enterprise инциденте: найти, изолировать, нейтрализовать. При инциденте в продакшене нужно следовать иным рекомендациям. Не отключать временные источники информации (most Volatility): registers, RAM, Cache, Process, пока данные не собраны и по возможности использовать в анализе Middle volatile – swap file.
Для Least volatile – HDD, сделать bit-by-bit образ диска, посчитать и сравнить хэш. Сделать копию образа и работать только с ней в режиме Read-only при необходимости. С сетевых устройств собрать информацию через Syslog, если развернута SIEM собрать отчеты, GiGo — сетевой трафик, учитывать временные сдвиги (time offset) для точного анализа (используйте NTP), скриншоты тоже бывают полезны, провести интервью с сотрудниками, если ничего не выходит, то нанять сотрудников со стороны (не забыть про соглашения), в обязательном порядке контролировать целостность при передаче информации от одного субъекта к другому (chain of custody).
Хочешь мира – готовься к войне! Как противостоять (Incident response).
Готовиться, готовиться, готовиться. Чем больше готовимся, тем меньше времени тратим на ответ. Необходимы правила, кого в первую очередь оповещать при возникновении проблемы (Начальника, Help-desk, ОИБ). Далее компетентные сотрудники должны определить приоритет: насколько важный, сложный, масштабы инцидента. Применить меры противодействия (изолировать, нейтрализовать). После устранения инцидента, обязательно обновить базу знаний (lessons learned), усовершенствовать технологии защиты, задокументировать инцидент, чтобы в следующий раз более эффективно реагировать или изменить инфраструктуру и политики так (policy & infrastructure update), чтобы вероятность возникновения данного типа инцидента была бы минимальной. При крайней необходимости обратиться в правоохранительные органы, однако стоит учитывать тот факт, что при проведении расследования можно получить очень «хорошие грабли» и дополнительные репутационные риски. «Не уверен, не обгоняй!». После процедур реагирования на инцидент и оценки последствий, необходимо привести инфраструктуру в рабочее состояние. Для этого в организации должен быть разработан план восстановления — «Disaster/recovery plan».
Обучение информационной безопасности – оповещен, значит вооружен.
С сотрудниками необходимо периодически проводить тренинг по ИБ, с дальнейшей проверкой знаний по вопросам, касающимся их операционной деятельности. В идеале это должно дисциплинировать пользователей, что в итоге приводит к снижению риска. По крайней мере контроль знаний заставляет пользователей запоминать основные аспекты политики ИБ.
Необходимо все данные категорировать (labeling) по важности/критичности, примерно таким образом, как это делается с информацией, составляющей ГТ, для коммерческой информации и в соответствии с законодательством касательно КИ и ПДн. В банках предусматривается своя категоризация относительно финансовой документации. Для такой информации применяется мандатная политика доступа (MAC) и пользователи должны понимать, что доступ к информации определяется исключительно производственной необходимостью. Обработка, транспортировка и уничтожение критичной информации аналогично должно производится корректно в соответствии с нормативной документацией. ГТ в мусорную корзину не выбрасывать и жесткие диски не перепродавать =)
Привычки пользователей тоже больная тема: пароли под клавиатурой, незаблокированный компьютер, оставленные документы на столе, найденные около офиса флэшки, помощь «незнакомым» людям попасть в офис — все это должно быть исключено и объяснено на реальных примерах и возникающих рисках, как для организации, так и для пользователя (лишение премии, административная ответственность и т.п.). Ко всему надо добавить и правила использования социальных сетей (если они не запрещены), открытии ссылок и рекламных объявлений, «любимых» пользовательских интернет ресурсов.
В продакшене могут встречаться и Natural disaster risks – природные и техногенные риски (пожар, землетрясение, наводнение, молния), которые могут притормозить производственную деятельность. Для ускорения процесса возврата к нормальному функционирования желательно иметь BCP – business continuity plan – концептуальные действия, основной частью которого является BIA – business impact analysis.
В нем нужно определить критично-важные системы, связи и их влияние на непрерывность бизнеса. Установить RTO, RPO, к которым нужно стремиться. Иметь несколько сценариев, оценить риски, желательно количественно. Определить возможные потери части бизнеса и штрафы от регуляторов.
Например, мы решили развернуть Hot site – это круто, но очень дорого. Если что-то происходит с основным сайтом, горячий резерв, имея всю информацию и технические возможности дубликата (Fully operational) выполнит замену. Хотим сэкономить – Warm site: требует больше времени для ввода в эксплуатацию, не имеет операционной информации, является только копией аппаратного обеспечения. Вообще нищеброды малобюджетная организация – хотя бы организовать cold site, ну или ничего… Как понимаете, все зависит от ценности активов.
Таким образом разрабатываемый Disaster recovery plan должен опираться на имеющиеся активы организации. При изменении активов он пересматривается и постоянно подвергается процедуре мониторинга. Из этого следует что BCP -> 1 DRP + 2 DRP + … + n DRP -> IT contingency plans для каждого DRP. IT contingency plan оценивает single system или asset. Для того чтобы знать, что делать при чрезвычайных ситуациях – разрабатывают Succession planning, есть смысл его разработать исключительно до наступления этих ситуаций.
Про избыточность (redundancy) и отказоустойчивость (fault tolerance), которые порождают реализацию HA — > Clustering — > Load Balancing говорили выше. К этому же можно и отнести RedundantArraryID (RAID): 0 – стрип, 1 – зеркало, 5, 6 – с битом, комбинированные 10, 50 и 60. Применение этих технических средств и технологий — best practice при проектировании BCP.
Backup plan. Здесь необходимо определить, как часто необходимо делать бэкапы и их объемы: полный, инкрементальный и дифференциальный. Обычно полные бэкапы делают на выходных, инкрементные вечером рабочего дня. Да, и бэкапить нужно только то, что действительно нужно, всяким мусором захламлять СХД смысла нет.
Итого, в заметке попытался рассказать про методы управления ИБ, оценке рисков и немного про технологии. Вспоминая работу на предприятии, опасного вида деятельности, могу сказать, что описанные выше концепты, действительно очень важны и часто выручают, как при работе с интеграторами и подрядчиками, так и при ЧП, когда возникает необходимость в срочном «переезде» инфраструктуры.
Как всегда рад буду увидеть ваши комментарии.
Понимаю, что объем великоват, поэтому спасибо, что осилили до конца!
Автор: kimssster
