16 ноября компания Optiv Security объявила о покупке компании Decision Lab, занимающейся большими данными, а также оркестрацией и автоматизацией. Сумма сделки не сообщается.
17.11.17
Управление логами - фундамент любой SIEM, в котором часто зияют прорехи
Уже совсем скоро пройдет конференция ЦБИ "Мониторинг ИБ: проблемы построения и эксплуатации", на которой я буду вести секцию про полноту и "доступность" источников информации, которые подключаются к SIEM, а потом на их основе работает SOC и принимаются решения о наличии или отсутствии угроз. По сути именно от того, насколько выстроена работа с источниками зависит эффективность всей системы кибербезопасности.
Давайте вспомним вот эту иллюстрацию двухнедельной давности:
В ней атомарным элементом считаются логи. Все логи сразу. Многие компании, да и производители SIEM, могут сказать, что уже они то выстроили достаточно зрелый, может быть даже на пятом уровне, процесс управления логами. И в принципе, не сильно задумываясь, мы можем с ними согласиться, так как о том, как работать с логами, как одним из источников информации ИБ, говорят уже много лет и даже десятилетий. Первые хостовые IDS, появившиеся в начале 80-х годов, как раз опирались в своей работе на данные из журналов регистрации. Можно предположить, что уж с логами-то за почти 40 лет у нас научились работать. Но история умеет преподносить сюрпризы. Вот так выглядит слайд из вчерашней презентации Антона Чувакина из Gartner, который рассказывал про технологию пользовательской поведенческой аналитики (UEBA):
Обратите внимания на первый пункт в списке основных проблем при внедрении и использовании UEBA - сбор данных, их доступность и качество. И это спустя 40 лет после появления первых хостовых IDS и 20 лет после появления первых SIEM. А ведь SIEM, которые в принципе должны уметь работать с источниками данных, потом отдают информацию в UEBA, а также иные системы аналитики ИБ.
Давайте вспомним вот эту иллюстрацию двухнедельной давности:
Обратите внимания на первый пункт в списке основных проблем при внедрении и использовании UEBA - сбор данных, их доступность и качество. И это спустя 40 лет после появления первых хостовых IDS и 20 лет после появления первых SIEM. А ведь SIEM, которые в принципе должны уметь работать с источниками данных, потом отдают информацию в UEBA, а также иные системы аналитики ИБ.
Но если источники данных плохие, то и все принятые на их основе решения тоже можно поставить под сомнение. В "лучшем" случае мы просто будем пропускать атаки и инциденты, а в худшем - пойдем по неверному пути, принимая неверные решения, тратя ресурсы не на то.
Какие проблемы можно выделить при работе с источниками информации? Их немало:
- Множество источников. Это примерно как с DLP, которые вроде и борются с утечками, но когда начинаешь копать, то оказывается, что 2/3 коммуникационных каналов в вашей компании они вообще не отслеживают.
- Противоречивость данных. Например, в одном источнике у вас указан IP-адрес, но нет, допустим, имени пользователя, а в другом наоборот - имя пользователя есть, а IP-адреса нет. И как связать такие данные между собой? А вот еще простой пример. В одном логе у вас время события записано в формате DD-MMM-YYYY, а в другом - MMDDYYYY. Хорошо, если система управления логами, приводит все к единому формату, а если нет?
- Противоречивость временных меток. Ну тут все понятно и дело даже не в разных часовых поясах, в которых могли происходить события, а в отсутствии системы синхронизации, что может привести, например, к ситуации, когда в SIEM числится, что события А произошло после события Б через 66 секунд, а на самом деле оно произошло до - на 15 секунд.
- Множество разных форматов. XML, JSON, syslog, CSV (с разделениями табуляцией или запятыми), SNMP, REST, базы данных и др.
- Незащищенность логов. Кто мешает злоумышленнику удалить какие-то записи из источника информации или, что еще хуже, подменить их, создавая и поддерживая ложное чувство защищенности? А что с доступностью источников информации?
- Способы доступа к источникам информации. Часто в описании SIEM/LM написано, что они поддерживают потоковые данные из syslog (а Netflow как, кстати?) и удаленный доступ к логам через API и удаленный доступ. А что с агентами? Некоторые данные без агентов не вытащить и не проанализировать.
- Неструктурированные данные. Правда, это не совсем задача SIEM или LM, но без них сегодня сложно проводить серьезную аналитику и принимать решения и поэтому стоит задуматься об этой теме заранее.
- Отсутствие стандартов или отказ от поддержки вендорами уже существующих стандартов. RDEP, CEE, SDEE, IODEF, RID, SecDEF... Их поддерживают средства защиты или системы анализа?
Разумеется, все эти проблемы могут быть решены, но об этом все-таки лучше поинтересоваться у производителя SIEM/UEBA/NTA/IDS и других ИБ-решений. Ну а если вы пишете систему защиты/аналитики сами, то просто подумайте, как вы будете решать эти проблемы? Вот именно этим вопросам и будет посвящена секция на конференции ЦБИ, которую я модерирую. Выступать в ней будут представители:
- ЦБИ, которые недавно выпустили свою SIEM Neurodat,
- НТЦ Вулкан, которые активно развивают направление SIEM в своих проектах,
- Infowatch
- Код безопасности
- РТ-Информ
- R-Vision
и их ждут непростые вопросы от меня :-)
15.11.17
Что такое Fusion Center и чем он отличается от SOC? #socforum
На прошлой неделе, в Питере, на конференции Secure It World, мне довелось модерировать секцию по безопасности ИТ-инфраструктуры, где выступал представитель Ростелекома с рассказом о том, как у них выстроен SOC. Очень интересный был доклад, но меня в нем, помимо прочего, заинтересовала вот эта иллюстрация:
Меня заинтересовала нижная часть слайда, в которой упоминается Fusion Center. Это второй раз, когда я вижу упоминание этого термина в контексте информационной безопасности. Первым был Сбербанк, который последний год упоминает (и еще тут) этот термин в контексте стратегии развития своего центра мониторинга ИБ.
Вообще, мне кажется, что произошла некоторая подмена понятий у тех, кто стал применять этот термин. Допускаю, что моду задал, как обычно, Герман Оскарович, увидевший где-то работающий Fusion Center и вбросивший этот термин журналистам, которые за него ухватились. А потом пошло поехало - термин прочно прилип к информационной безопасности и его сейчас стал применять Ростелеком (не исключая, что скоро подтянутся и другие). Но все-таки, Fusion Center имеет очень опосредованное отношение к мониторингу ИБ в привычном понимании. Да и в отдельно взятой организации Fusion Center построить трудновато. Почему?
Дело в том, что в США, а именно туда пошла концепция Fusion Center в 2003-м году, это центры обмена информацией, а не круглосуточного мониторинга ИБ. Более того, первоначально, да и сейчас, эти центры не имели ничего общего с кибербезопасностью. Они создавались под эгидой Министерства национальной безопасности (DHS) или Минюста (а позже и на уровне отдельных госорганов или муниципалитетов) и позволяли обмениваться стратегической информацией между ЦРУ, ФБР, МинОбороны, МЧС, а также локальными администрациями и т.д. В первые годы Fusion Center, а их насчитывалось только в США несколько десятков, были достаточно бестолковы - они обменивалсь плохо структурированной информацией, которую сложно было анализировать, искать в ней взаимозависимости и строить на ее основе какие-то выводы и принимать решения. Например, в 2011-м году Fusion Center в Иллинойсе сообщил о взломе насосной станции системы водоснабжения в Иллинойсе. Позже агенты ФБР опровергли данное заявление, доказав, что речь шла о легальном удаленном доступе администратора насосной станции.
Если вы введете в Google поиск по картинкам с ключевой фразой "fusion center", то вы увидите кучу фотографий больших залов, напичканных кучей мониторов, за которыми сидят люди и пялятся в экраны. Это не fusion center, хотя его именно так многие и представляют. Отсюда и попытка применить этот термин в ИБ, в которой есть свои SOCи c кучей плазм и больших мониторов. Fusion center - это и не центр реагирования на инциденты, хотя иногда такая функция в нем и встречается, но она не основная. Fusion center не выполняет никаких оперативных функций - это центр поддержки, базирующийся на анализе разрозненных данных. Наиболее близки к концепции Fusion Center CDC (Cyber Defence Center) или ISAC (Information Sharing and Analysis Center), но и они все-таки работают преимущественно со структурированной информацией, в то время как Fusion Center работает с обоими типами данных - структурированными и не очень (особенно с последней). Это позволяет, за счет различных алгоритм и матмоделей, предсказывать многие инциденты и купировать их в зародыше.
При этом речь идет не об инцидентах ИБ, а обо всех типах событий, которые могут привести к эпидемиям, пожарам, народным волнения, забастовкам, землетрясениям, наводнениям и т.п. природным и искусственным стихийным бедствиям. У нас же почему-то идею Fusion Center выхолостили до одной киберсоставляющей, по сутя говоря о Security Intelligence Center (SIC). Это пока нечасто упоминаемая концепция, которая как раз и описывает центр мониторинга, предсказывающий угрозы на базе продвинутой аналитики (про него я еще напишу).
ЗЫ. Кстати, на модерируемой мной секции Future SOC на SOC Forum будет выступление Алексея Качалина из Сбербанка, который будет рассказывать о своем видении будущего SOC через 8 лет. Не видя еще презентации, могу предположить, что во-многом она будет базироваться на том, каким видит свой Fusion Center Сбербанк в 2025-м году. А Эльман Бейбутов на той же секции будет рассказывать как раз про продвинутую аналитику в деле ИБ. Приходите, будет интересно.
ЗЗЫ. На сайте DHS много полезных руководств по созданию и эксплуатации Fusion Center. Есть там и руководства по интеграции в Fusion Center тематики кибербезопасности.
Меня заинтересовала нижная часть слайда, в которой упоминается Fusion Center. Это второй раз, когда я вижу упоминание этого термина в контексте информационной безопасности. Первым был Сбербанк, который последний год упоминает (и еще тут) этот термин в контексте стратегии развития своего центра мониторинга ИБ.
 |
| SOC Сбербанка |
Дело в том, что в США, а именно туда пошла концепция Fusion Center в 2003-м году, это центры обмена информацией, а не круглосуточного мониторинга ИБ. Более того, первоначально, да и сейчас, эти центры не имели ничего общего с кибербезопасностью. Они создавались под эгидой Министерства национальной безопасности (DHS) или Минюста (а позже и на уровне отдельных госорганов или муниципалитетов) и позволяли обмениваться стратегической информацией между ЦРУ, ФБР, МинОбороны, МЧС, а также локальными администрациями и т.д. В первые годы Fusion Center, а их насчитывалось только в США несколько десятков, были достаточно бестолковы - они обменивалсь плохо структурированной информацией, которую сложно было анализировать, искать в ней взаимозависимости и строить на ее основе какие-то выводы и принимать решения. Например, в 2011-м году Fusion Center в Иллинойсе сообщил о взломе насосной станции системы водоснабжения в Иллинойсе. Позже агенты ФБР опровергли данное заявление, доказав, что речь шла о легальном удаленном доступе администратора насосной станции.
Если вы введете в Google поиск по картинкам с ключевой фразой "fusion center", то вы увидите кучу фотографий больших залов, напичканных кучей мониторов, за которыми сидят люди и пялятся в экраны. Это не fusion center, хотя его именно так многие и представляют. Отсюда и попытка применить этот термин в ИБ, в которой есть свои SOCи c кучей плазм и больших мониторов. Fusion center - это и не центр реагирования на инциденты, хотя иногда такая функция в нем и встречается, но она не основная. Fusion center не выполняет никаких оперативных функций - это центр поддержки, базирующийся на анализе разрозненных данных. Наиболее близки к концепции Fusion Center CDC (Cyber Defence Center) или ISAC (Information Sharing and Analysis Center), но и они все-таки работают преимущественно со структурированной информацией, в то время как Fusion Center работает с обоими типами данных - структурированными и не очень (особенно с последней). Это позволяет, за счет различных алгоритм и матмоделей, предсказывать многие инциденты и купировать их в зародыше.
При этом речь идет не об инцидентах ИБ, а обо всех типах событий, которые могут привести к эпидемиям, пожарам, народным волнения, забастовкам, землетрясениям, наводнениям и т.п. природным и искусственным стихийным бедствиям. У нас же почему-то идею Fusion Center выхолостили до одной киберсоставляющей, по сутя говоря о Security Intelligence Center (SIC). Это пока нечасто упоминаемая концепция, которая как раз и описывает центр мониторинга, предсказывающий угрозы на базе продвинутой аналитики (про него я еще напишу).
ЗЫ. Кстати, на модерируемой мной секции Future SOC на SOC Forum будет выступление Алексея Качалина из Сбербанка, который будет рассказывать о своем видении будущего SOC через 8 лет. Не видя еще презентации, могу предположить, что во-многом она будет базироваться на том, каким видит свой Fusion Center Сбербанк в 2025-м году. А Эльман Бейбутов на той же секции будет рассказывать как раз про продвинутую аналитику в деле ИБ. Приходите, будет интересно.
ЗЗЫ. На сайте DHS много полезных руководств по созданию и эксплуатации Fusion Center. Есть там и руководства по интеграции в Fusion Center тематики кибербезопасности.
14.11.17
Какие стандарты будет применять ГосСОПКА для получения карточек инцидентов и раздачи индикаторов компрометации? #socforum
В предверии SOC Forum хочу вернуться к теме, которую я уже не раз поднимал и важность которой становится все острее и острее. Речь идет о стандартизации обмена информацией об угрозах, инцидентах и индикаторах компрометации между ГосСОПКОЙ и сегментами/центрами ГосСОПКИ.
Сейчас уже существует временная форма карточки инцидента, разработанная 8-м Центром ФСБ и представленная в формате XML. Это очень важный шаг в стандартизации обмена информацией об инцидентах, которые будут передаваться в ГосСОПКУ. Эту же карточку с высокой вероятностью будет использовать и ФинЦЕРТ при своем взаимодействии с финансовыми организациями, которые обязаны сообщать об инцидентах в своей инфраструктуре. Пока рано говорить о том, насколько предложенный формат карточки инцидента совпадает с признанным во всем мире стандартом STIX, о котором я уже писал 4 года назад. Меня гораздо больше интересует другой вопрос. Разработан ли протокол обмена такими карточками инцидентов и каков формат данных об индикаторах компрометации, которые НКЦКИ должен будет рассылать по своим подопечным. В методических рекомендациях по созданию корпоративных и ведомственных центров ГосСОПКИ тема взаимодействия описана очень скупо. Более того, слово "индивидуально" меня смущает - оно так напоминает классическое "в частном порядке", которое очень любят представители 8-го Центра, которым задают вопросы по криптографии.
Как может выглядеть взаимодействие с ГосСОПКОЙ? Я бы выделил несколько вариантов передачи данных по инцидентам:
Я надеюсь, что к 1-му января 2018-го года уже наступит ясность (а может ее внесут уже на SOC Forum, где по ГосСОПКЕ будет отдельная секция с 3-мя докладами представителей ФСБ) по вопросу взаимодействия с ГосСОПКОЙ, так как в противном случае возможны самые нехорошие последствия. Например, дополнительные затраты (в том числе бюджетные) на приобретение решений, которые только и поддерживают протокол, разработанный в ФСБ. Сейчас уже ходяит по рынку компания, которая заверяет заказчиков, что она единственная, кто уполномочена ФСБ разрабатывать шлюз взаимодействия с ГосСОПКОЙ и что надо в обязательном порядке приобрести ее шлюз, который будет транслировать данные из имеющихся у заказчиков решений в понимаемый ГосСОПКОЙ формат. А это уже потенциально обвинения в монополии и другией репутационные риски.
А что делать с уже имеющими у многих заказчиков SIEM, которые работают годами и их никто не планирует выбрасывать на свалку и заменять на что-то отечественное (при всем выбранном на импортозамещение курсе)? В идеале им бы выдать описание формата карточки инцидента (это будет сделано) и описание протокола, под который можно написать соответствующий коннектор и подцепить к SIEM или IRP (будь-то QRadar, ArcSight, LogRhytm, Splunk, R-Vision, IBM Resilient и т.п.). Тогда затраты, включая и бюджетные, будут гораздо ниже, чем в случае использования отдельного "православного" шлюза.
С получением данных Threat Intelligence от ГосСОПКИ ситуация и проще и сложнее одновременно. Про то, какой формат будет использовать для передачи индикаторов компрометации пока не говорится. Это может быть OpenIOC, это может быть CybOX, это может быть STIX и т.п. Наверное, это был бы самый правильный вариант, чтобы не плодить промежуточные конверторы из принятых в мире стандартов в нечто, что понимается только ГосСОПКОЙ. И с одной стороны ГосСОПКА не чурается применения международных (читай, американских) стандартов, например, TLP:
и сигнатуры атак описывает на языке стандарта дефакто в области обнаружения атак - Snort:
Сейчас уже существует временная форма карточки инцидента, разработанная 8-м Центром ФСБ и представленная в формате XML. Это очень важный шаг в стандартизации обмена информацией об инцидентах, которые будут передаваться в ГосСОПКУ. Эту же карточку с высокой вероятностью будет использовать и ФинЦЕРТ при своем взаимодействии с финансовыми организациями, которые обязаны сообщать об инцидентах в своей инфраструктуре. Пока рано говорить о том, насколько предложенный формат карточки инцидента совпадает с признанным во всем мире стандартом STIX, о котором я уже писал 4 года назад. Меня гораздо больше интересует другой вопрос. Разработан ли протокол обмена такими карточками инцидентов и каков формат данных об индикаторах компрометации, которые НКЦКИ должен будет рассылать по своим подопечным. В методических рекомендациях по созданию корпоративных и ведомственных центров ГосСОПКИ тема взаимодействия описана очень скупо. Более того, слово "индивидуально" меня смущает - оно так напоминает классическое "в частном порядке", которое очень любят представители 8-го Центра, которым задают вопросы по криптографии.
Как может выглядеть взаимодействие с ГосСОПКОЙ? Я бы выделил несколько вариантов передачи данных по инцидентам:
- Старая добрая электронная почта, по которой будут отправляться карточки инцидентов на заранее определенный ящик (так делается сейчас в рамках взаимодействия с ФинЦЕРТ). Если не рассматривать вариант, что этот канал слабо защищен и может потребоваться внедрение средств обеспечения целостности и конфиденциальности (разумеется, на ГОСТе и сертифицированных), то возникает сложность с автоматизацией процесса разбора таких сообщений e-mail на стороне ГосСОПКИ. Конечно, это не наша проблема, но мы же сейчас рассуждаем о всей схеме.
- Система личных кабинетов, которую планируют к концу следующего года внедрить в ФинЦЕРТе и вроде такие же слухи ходят и про ГосСОПКУ. Иными словами участник информационного обмена должен будет самостоятельно заливать карточки об инцидентах в личный кабинет, а оттуда она уже попадет в системы аналитики. Тут тоже возникает вопрос с автоматизацией данного действа - будет ли какой-то API для залива (с токенизацией, конечно, для защиты от подмены) или все надо будет делать вручную?
- API для взаимодействия по специальному протоколу (например, TAXI), который позволит унифицировать процедуру и автоматизировать ее. На мой взгляд, это был бы идеальный вариант, учитывая известность TAXI и его поддержку многими производителями средств защиты и мониторинга (те же SIEM).
А что делать с уже имеющими у многих заказчиков SIEM, которые работают годами и их никто не планирует выбрасывать на свалку и заменять на что-то отечественное (при всем выбранном на импортозамещение курсе)? В идеале им бы выдать описание формата карточки инцидента (это будет сделано) и описание протокола, под который можно написать соответствующий коннектор и подцепить к SIEM или IRP (будь-то QRadar, ArcSight, LogRhytm, Splunk, R-Vision, IBM Resilient и т.п.). Тогда затраты, включая и бюджетные, будут гораздо ниже, чем в случае использования отдельного "православного" шлюза.
С получением данных Threat Intelligence от ГосСОПКИ ситуация и проще и сложнее одновременно. Про то, какой формат будет использовать для передачи индикаторов компрометации пока не говорится. Это может быть OpenIOC, это может быть CybOX, это может быть STIX и т.п. Наверное, это был бы самый правильный вариант, чтобы не плодить промежуточные конверторы из принятых в мире стандартов в нечто, что понимается только ГосСОПКОЙ. И с одной стороны ГосСОПКА не чурается применения международных (читай, американских) стандартов, например, TLP:
и сигнатуры атак описывает на языке стандарта дефакто в области обнаружения атак - Snort:
С другой стороны возможны и геополитические нюансы, запрещающие активно применять все (даже стандарты и протоколы), что идет со стороны потенциального противника (такая идея иногда звучит в коридорах власти).
С протоколом передачи IoC от ГосСОПКИ пока тоже ясности нет. PDFки или Word'овые документы тут не подойдут - опять же нужна стандартизация для последующей автоматизации процесса. TAXI? CSV (тоже вариант, кстати)? API, с помощью которого можно будет периодически заходить на сайт НКЦКИ и сгружать оттуда новые индикаторы? Или снова личный кабинет и e-mail? Нет ответа.
И это мы еще не наложили на данную схему требование применения сертифицированных СКЗИ при взаимодействии с ГосСОПКОЙ. Встроенных в SIEM сертифицированных СКЗИ я что-то не припомню (может просто не знаю). Значит наложенная VPN-сеть? А какие VPN-шлюзы будут применяться в ГосСОПКЕ? Один выбранный производитель (а что делать, если у заказчика закуплены решения другого?) или будет кластер из шлюзов всех вендоров?
Подводя итог, хочется отметить, что воможно я дую на воду и все описанные в заметке вопросы уже решены и ФСБ готовит пакет документов и разъяснений по тому, как интегрироваться с ГосСОПКОЙ. Возможно на SOC Forum будут даны ответы на все вопросы, которые возникают не только у меня, но и у многих коллег по цеху, которые не всегда имеют возможность задать их представителям 8-го Центра.
ЗЗЫ. Интересно, а если для карточки инцидента будет применяться JSON, то решены ли с ним вопросы безопасности? На последнем BlackHat, в июле, был интересный доклад по атакам на JSON. Вообще это благодарная тема - атаки на JSON рассматриваются уже не первый год (например, тут или тут). Обработка JSON в ГосСОПКЕ лишена этих проблем?
13.11.17
Гримасы импортозамещения в контексте мировых тенденций ИБ (парадоксы и презентации)
На прошлой неделе довелось участвовать в питерской конференции по ИБ Secure It World. Прекрасное мероприятие, прекрасная компания, прекрасные доклады.
Мне довелось выступать с трендовой презентацией, в которой я попробовал включить все ключевые тенденции рынка ИБ, которые я вижу в мире (не обязательно, что все они дойдут до России, но знать о них стоит). Презентацию по ней выкладываю (ссылка ведет на SlideShare, доступ к которому в России запрещен):
Также я модерировал секцию по защите ИТ-инфраструктуры, где из 6 докладов целых 3 выступления было посвящено теме SOCов (от Solar, Ростелекома и Техносерва), но про них я еще напишу отдельно. Доклад Group-IB был посвящен трендам киберпреступности. Но отдельно я бы хотел отметить доклад Конфидента, который задался закономерным вопросом - насколько совместимы требования по ИБ от регуляторов и курс на импортозамещение. И дальше с цифрами в руках они показали текущую несовместимость этих двух миров :-)
Крутится все вокруг российских операционных систем. Парадоксальный факт. При наличии 30 отечественных ОС в реестре Минкомсвязи и 40 ОС в реестре ФСТЭК, пересечение между ними происходит всего в 4 случаях. То есть всего 4 ОС (две версии ALT Linux, Астра и Синергия) считаются российскими и имеют сертификаты ФСТЭК. И только одна сертифицирована по новым РД ФСТЭК к ОС. То есть получается, что заказчик, который всерьез задумывается о реальном импортозамещении не имеет большого выбора в части отечественных ОС.
Второй интересный момент касается сертифицированных средств защиты. Большинство якобы российских программных продуктов по-прежнему рассчитано на работу только с Windows. Для российских ОС средств защиты почти нет. А если взять за основу 17-й приказ ФСТЭК и посмотреть, какие меры защиты входят в базовый набор и должны использоваться для защиты ГИС, то получается, что... реализовать 17-й приказ на базе отечественных ОС нельзя в принципе. Как минимум, нет тех же средств контроля машинных носителей, с СОВами тоже проблема. Да и сертифицированные МСЭ далеко не всегда работают на отечественных защищенных ОС.
Конфидент делает с одной стороны парадоксальный, а с другой вполне реальный вывод, что аттестовать ГИС, в которой решили использовать отечественные ОС, нельзя.
Ну и еще одно наблюдение Конфидента, который решил проанализировать, насколько эффективно в российских сертифицированных ОС выстроен процесс устранения уязвимостей. Предсказуемо, но процесс не самый лучший и не самый оперативный, существенно уступающий и родным Linux, с которых клонированы "отечественные" ОС, и уступающий Windows.
Вроде и ничего нового не было в презентации Конфидента, но мне понравилась подача материала и реально проведенное исследование непростой ситуации с расхождением курса на импортозамещение и его поддержкой рынком ИБ, который пока не сильно стремится поддержать отечественного производяителя на деле (на словах все готовы).
Мне довелось выступать с трендовой презентацией, в которой я попробовал включить все ключевые тенденции рынка ИБ, которые я вижу в мире (не обязательно, что все они дойдут до России, но знать о них стоит). Презентацию по ней выкладываю (ссылка ведет на SlideShare, доступ к которому в России запрещен):
Также я модерировал секцию по защите ИТ-инфраструктуры, где из 6 докладов целых 3 выступления было посвящено теме SOCов (от Solar, Ростелекома и Техносерва), но про них я еще напишу отдельно. Доклад Group-IB был посвящен трендам киберпреступности. Но отдельно я бы хотел отметить доклад Конфидента, который задался закономерным вопросом - насколько совместимы требования по ИБ от регуляторов и курс на импортозамещение. И дальше с цифрами в руках они показали текущую несовместимость этих двух миров :-)
Крутится все вокруг российских операционных систем. Парадоксальный факт. При наличии 30 отечественных ОС в реестре Минкомсвязи и 40 ОС в реестре ФСТЭК, пересечение между ними происходит всего в 4 случаях. То есть всего 4 ОС (две версии ALT Linux, Астра и Синергия) считаются российскими и имеют сертификаты ФСТЭК. И только одна сертифицирована по новым РД ФСТЭК к ОС. То есть получается, что заказчик, который всерьез задумывается о реальном импортозамещении не имеет большого выбора в части отечественных ОС.
Второй интересный момент касается сертифицированных средств защиты. Большинство якобы российских программных продуктов по-прежнему рассчитано на работу только с Windows. Для российских ОС средств защиты почти нет. А если взять за основу 17-й приказ ФСТЭК и посмотреть, какие меры защиты входят в базовый набор и должны использоваться для защиты ГИС, то получается, что... реализовать 17-й приказ на базе отечественных ОС нельзя в принципе. Как минимум, нет тех же средств контроля машинных носителей, с СОВами тоже проблема. Да и сертифицированные МСЭ далеко не всегда работают на отечественных защищенных ОС.
Конфидент делает с одной стороны парадоксальный, а с другой вполне реальный вывод, что аттестовать ГИС, в которой решили использовать отечественные ОС, нельзя.
Ну и еще одно наблюдение Конфидента, который решил проанализировать, насколько эффективно в российских сертифицированных ОС выстроен процесс устранения уязвимостей. Предсказуемо, но процесс не самый лучший и не самый оперативный, существенно уступающий и родным Linux, с которых клонированы "отечественные" ОС, и уступающий Windows.
Вроде и ничего нового не было в презентации Конфидента, но мне понравилась подача материала и реально проведенное исследование непростой ситуации с расхождением курса на импортозамещение и его поддержкой рынком ИБ, который пока не сильно стремится поддержать отечественного производяителя на деле (на словах все готовы).
10.11.17
Кто такие "русские хакеры" и есть ли у России кибервойска?
В последние несколько недель, с момента начала конфликта с Лабораторией Касперского, мне постоянно звонят журналисты иностранных изданий, аккредитованных в России, с просьбой прокомментировать ряд вопросов, которые, как им кажется, являются уникальными и очень интересными. Первый раз это выглядело забавно. Второй я уже отвечал по накатанной. На третий раз я начал злиться. Когда одни и те же вопросы я услышал раз в десятый, я решил написать эту заметку, а окончательно оформилась она вчера, во время перелета на конференцию Secure It World в Питере.
Вопросов обычно звучит три:
Ну ответ на первый вопрос я оставлю за рамками этой заметки, а вот на остальные два отвечу и буду потом давать просто ссылку на нее, когда мне в очередьной раз зададут "уникальные и интересные" вопросы.
Итак, начнем с конца, поговорим про русских хакеров, которые ломают всечто движется и всех. Стоит преклонить голову перед пропагандистской машиной США, которые убедили весь мир, что во всем виноваты русские хакеры. Проигрыш демократов Трампу? Русские хакеры. Раздолбайство Yahoo? Русские хакеры. Из ЦРУ и АНБ утекли секретные архивы кибероружия? Русские хакеры. Домогательство Кевина Спейси к Вайнстайну (или Вайнштейну)? Не удивлюсь, если тоже скоро найдут следы русских хакеров. Скоро и Stuxnet на наших повесят. Конечно, внутри, меня переполняет гордость за нашу страну, которая поставила всех на колени своими невидимимыми кибервойсками. Но вот за пределами страны от этого только хуже. Запущенный США маховик раскручивается и даже лояльные и независимые специалисты, компании, организации начинают задумываться, что нет дыма без огня.
А противопоставить нам нечего :-( У нас за всю страну отдувается одна Мария Захарова, которая комментирует абсолютно все выпады в нашу сторону. Но в ИБ нет своей Захаровой, а в МИДе нет грамотных безопасников, которые могли бы дать фактуру, отвечать на вопросы журналистов, готовить материалы. Вот по военной кампании в Сирии я регулярно вижу в СМИ выступления Конашенкова из МинОбороны, который показывает всякие спутниковые снимки, видео, доклады экспертов, карты и т.п. Ему можно верить или не верить, но выглядит это солидно. Неспециалисты верят (может и специалисты тоже). А вот по части кибербезопасности у нас нет своего Конашенкова. ФСБ молчит. СовБез молчит. ФСТЭК молчит. Минкомсвязи молчит. И только Госдума и Совет Федерации иногда выступят с разгромной речью, которая укладывается в простое "А вы докажите". И в итоге Россия проигрывает; независимо от того, виновата она или нет. Даже если признать, что мы ломаем всех и все, то от этого не легче. Гордость гордостью, но такое амплуа сильно вредит во внешней политике и экономике.
Могла ли Россия (прогосударственные хакеры) взломать все иностранные государства, в атаке на которые нас обвиняли? Да, могла. Делала ли она это? Не уверен и вот почему. Для того, чтобы ломать все и всех нужны... нет, не кибероружие. Хотя и оно тоже, но утекшего арсенала из ЦРУ и АНБ достаточно, учитывая общий невысокий уровень кибербезопасности в мире. Нужны люди и много.
У Китая и США есть свои кибервойска, насчитывающие тысячи военнослужащих. У Израиля есть военное подразделение 8200, есть подразделения Matzov и Mamram. Даже у КНДР есть свои подразделения. А у нас нет. То есть нельзя сказать, что ФСБ, СВР, ГРУ игнорируют киберпространство и не используют его для проведения наступательных, оборонительных и разведывательных операций (было бы глупо так думать, когда весь мир устремляется в виртуальное пространство, а НАТО рассматривает его отдельным доменом для ведения боевых действий), но и отдельного огромного штата на тысячи человек у нас нет. Это журналистам можно проводить аналогии и считать, что раз в США и Китае есть, то и у нас тоже есть. Но мы-то, работающие не один год, знаем. Повторюсь. Я допускаю, что в наших спецслужбах есть те, кто может делать то, в чем их обвиняют, но чтобы их были тысячи или даже сотни?.. Вот тут у меня есть сомнения.
Ибо нет инфраструктуры для подготовки такого штата специалистов. Я 25 лет в отрасли и не думаю, что мог пропустить подготовку такого количества экспертов по наступательным кибервооружениям. Вот в Израиле, например, есть специальная программа Talpiot, которая направлена на то, чтобы выискивать и нанимать на военную службу тех, кто демонстрирует соответствующие навыки, которые могут быть полезны для военной программы Израиля. В СССР, кстати, такая программа тоже была. Помню меня в последнем классе вызвала как-то к себе директрисса, в кабинете которой поджидал "человек в штатском", который пригласил меня после школьных экзаменов в Академию КГБ и все такое. Сейчас спецслужбы тоже присматриваются к различным одаренным молодым "кадетам". Но заинтересовать их уже сложно. Престижной, как было в советское время, служба в органах уже не считается. Больших зарплат там нет, перспектив тоже (это на Западе, не у нас, выходцы из спецслужб или военного ведомства создают огромное количество стартапов по ИБ). Поэтому идут в спецслужбы не так уж и много выпускников школ или ВУЗов.
Можно, конечно, искать среди преступных элементов, но много ли их? Бывший агент ФБР утверждает, что Россия нанимает на работу хакеров, обвиняемых в киберпреступлениях в разных странах мира, давая им иммунитет. Об этом же пишет из тюрьмы арестованный за госизмену Руслан Стоянов, работавший в Лаборатории Касперского. Допускаю. Сделка со следствием - это популярная тема, особенно на Западе. Почему так много поимок хакеров именно в США? Отчасти потому, что там институт сделок со следствием очень развит и проще договориться сотрудничать, чем сесть на 30 лет. Не думаю, что Россия чем-то сильно отличается от всего мира в этом плане, разве что только количеством таких хакеров. Не верю я, что их тысячи и все они работают на государство. Учитывая культуру и свободолюбие этих людей, такой факт давно бы стал достоянием гласности, а у тех же американцев появились бы доказательство "русского следа". Но их нет. Возможно потому, что нет этих толп русских хакеров, которые якобы стоят за всеми последними крупными и не очень, известными и пока еще нет взломами.
Поэтому, в качестве резюме, я вполне допускаю, что мы могли вломиться куда-нибудь, но я не верю в массовость этого явления, которое приписывают русским хакерам. На вопрос, почему тогда нас все обвиняют, ответ простой - это выгодно нашим геополитическим соперникам. Известный факт - видишь в ком-то угрозу, не можешь его обыграть в честной борьбе, облей грязью и пусть он отмывается (если сможет). Что мы и видим. Поливают нас США и ее сателлиты, а мы... мы молчим, выбрав стратегию "не оправдываться". Правильная ли эта стратегия, покажет время.
Вопросов обычно звучит три:
- Как запрет США на поставки Лаборатории Касперского скажется на бизнесе компании?
- Действительно ли ИБ-компании сотрудничают со спецслужбами?
- Откуда русские государственные хакеры осуществляют свои атаки на весь мир?
Ну ответ на первый вопрос я оставлю за рамками этой заметки, а вот на остальные два отвечу и буду потом давать просто ссылку на нее, когда мне в очередьной раз зададут "уникальные и интересные" вопросы.
Итак, начнем с конца, поговорим про русских хакеров, которые ломают все
 |
| Следуя традиции скоро станет известно о хакерской группировке "Red Bear" |
А противопоставить нам нечего :-( У нас за всю страну отдувается одна Мария Захарова, которая комментирует абсолютно все выпады в нашу сторону. Но в ИБ нет своей Захаровой, а в МИДе нет грамотных безопасников, которые могли бы дать фактуру, отвечать на вопросы журналистов, готовить материалы. Вот по военной кампании в Сирии я регулярно вижу в СМИ выступления Конашенкова из МинОбороны, который показывает всякие спутниковые снимки, видео, доклады экспертов, карты и т.п. Ему можно верить или не верить, но выглядит это солидно. Неспециалисты верят (может и специалисты тоже). А вот по части кибербезопасности у нас нет своего Конашенкова. ФСБ молчит. СовБез молчит. ФСТЭК молчит. Минкомсвязи молчит. И только Госдума и Совет Федерации иногда выступят с разгромной речью, которая укладывается в простое "А вы докажите". И в итоге Россия проигрывает; независимо от того, виновата она или нет. Даже если признать, что мы ломаем всех и все, то от этого не легче. Гордость гордостью, но такое амплуа сильно вредит во внешней политике и экономике.
Могла ли Россия (прогосударственные хакеры) взломать все иностранные государства, в атаке на которые нас обвиняли? Да, могла. Делала ли она это? Не уверен и вот почему. Для того, чтобы ломать все и всех нужны... нет, не кибероружие. Хотя и оно тоже, но утекшего арсенала из ЦРУ и АНБ достаточно, учитывая общий невысокий уровень кибербезопасности в мире. Нужны люди и много.
У Китая и США есть свои кибервойска, насчитывающие тысячи военнослужащих. У Израиля есть военное подразделение 8200, есть подразделения Matzov и Mamram. Даже у КНДР есть свои подразделения. А у нас нет. То есть нельзя сказать, что ФСБ, СВР, ГРУ игнорируют киберпространство и не используют его для проведения наступательных, оборонительных и разведывательных операций (было бы глупо так думать, когда весь мир устремляется в виртуальное пространство, а НАТО рассматривает его отдельным доменом для ведения боевых действий), но и отдельного огромного штата на тысячи человек у нас нет. Это журналистам можно проводить аналогии и считать, что раз в США и Китае есть, то и у нас тоже есть. Но мы-то, работающие не один год, знаем. Повторюсь. Я допускаю, что в наших спецслужбах есть те, кто может делать то, в чем их обвиняют, но чтобы их были тысячи или даже сотни?.. Вот тут у меня есть сомнения.
Ибо нет инфраструктуры для подготовки такого штата специалистов. Я 25 лет в отрасли и не думаю, что мог пропустить подготовку такого количества экспертов по наступательным кибервооружениям. Вот в Израиле, например, есть специальная программа Talpiot, которая направлена на то, чтобы выискивать и нанимать на военную службу тех, кто демонстрирует соответствующие навыки, которые могут быть полезны для военной программы Израиля. В СССР, кстати, такая программа тоже была. Помню меня в последнем классе вызвала как-то к себе директрисса, в кабинете которой поджидал "человек в штатском", который пригласил меня после школьных экзаменов в Академию КГБ и все такое. Сейчас спецслужбы тоже присматриваются к различным одаренным молодым "кадетам". Но заинтересовать их уже сложно. Престижной, как было в советское время, служба в органах уже не считается. Больших зарплат там нет, перспектив тоже (это на Западе, не у нас, выходцы из спецслужб или военного ведомства создают огромное количество стартапов по ИБ). Поэтому идут в спецслужбы не так уж и много выпускников школ или ВУЗов.
Можно, конечно, искать среди преступных элементов, но много ли их? Бывший агент ФБР утверждает, что Россия нанимает на работу хакеров, обвиняемых в киберпреступлениях в разных странах мира, давая им иммунитет. Об этом же пишет из тюрьмы арестованный за госизмену Руслан Стоянов, работавший в Лаборатории Касперского. Допускаю. Сделка со следствием - это популярная тема, особенно на Западе. Почему так много поимок хакеров именно в США? Отчасти потому, что там институт сделок со следствием очень развит и проще договориться сотрудничать, чем сесть на 30 лет. Не думаю, что Россия чем-то сильно отличается от всего мира в этом плане, разве что только количеством таких хакеров. Не верю я, что их тысячи и все они работают на государство. Учитывая культуру и свободолюбие этих людей, такой факт давно бы стал достоянием гласности, а у тех же американцев появились бы доказательство "русского следа". Но их нет. Возможно потому, что нет этих толп русских хакеров, которые якобы стоят за всеми последними крупными и не очень, известными и пока еще нет взломами.
Поэтому, в качестве резюме, я вполне допускаю, что мы могли вломиться куда-нибудь, но я не верю в массовость этого явления, которое приписывают русским хакерам. На вопрос, почему тогда нас все обвиняют, ответ простой - это выгодно нашим геополитическим соперникам. Известный факт - видишь в ком-то угрозу, не можешь его обыграть в честной борьбе, облей грязью и пусть он отмывается (если сможет). Что мы и видим. Поливают нас США и ее сателлиты, а мы... мы молчим, выбрав стратегию "не оправдываться". Правильная ли эта стратегия, покажет время.
9.11.17
Symantec покупает SurfEasy
6 ноября Symantec объявила о покупке SurfEasy, разработчика VPN-решений, которым ранее владела Opera Software. Стоимость сделки составляет 38,5 миллионов долларов.
Proofpoint покупает Cloudmark
7 ноября Proofpoint подписала соглашение о приобретении Cloudmark, занимающейся защитой контента и threat intelligence для операторов связи. Размер сделки составил 110 миллионов долларов.
Future SOC - модерируемая мной секция на #socforum
По статистике полугодового отчета Cisco по информационной безопасности за 2017-й год 55% компаний, в том числе и в России, пользуются услугами от 6 до 50 поставщиков решений безопасности. А число организаций, которые используют более 6 различных продуктов по ИБ превышает 65%. Эти цифры означают, что как никогда возрастает необходимость внедрения в своих организациях систем мониторинга ИБ, позволяющих объединить данные с множества разрозненных средств защиты информации. С другой стороны мы сталкиваемся с ситуацией, когда несмотря на все попытки предотвращения угроз, мы не можем гарантировать этого. Неслучайно вся отрасль ИБ (по крайней мере мировая) смотрит в сторону обнаружения и реагирования на инциденты, которые позволяют минимизировать ущерб от действия киберпреступников. А значит на сцену выходит тема центров мониторинга ИБ (SOC), которые позволяют не только мониторить события безопасности, но и оперативно реагировать на них. Именно этому посвящены последние два, а также нынешний SOC Forum. Но…
Надо признать, что пока эта тема достаточно нова для российского потребителя, который часто путает SOC и SIEM, а программу управления инцидентами и соответствующие платформы IRP с требованиями по уведомлению регуляторов об обнаружении инцидентов ИБ в своей организации. Поэтому и темы, и вопросы, звучащие на SOC Forum пока носят базовый характер, так сказать «для начинающих» (что тоже важно). Однако это не значит, что помимо "азбуки" SOC, специалистов не интересуют продвинутые темы о применении в мониторинге ИБ Big Data, нейросетей, машинного обучения, блокчейна, когнитивных технологий, виртуальной реальности и других «модных словечек», о которых многие слышали, но не все знают о практике их применения. И не только вообще, но и в ИБ в частности. Именно поэтому в рамках SOC Forum было решено выделить целую секцию Future SOC и посвятить ее перспективным технологиям, которые только начинают применяться в современных центрах мониторинга ИБ. На секции будут и обзорные доклады о применении продвинутых аналитических методов в ИБ, и практические доклады для обмена опытом по использованию Big Data в деятельности одного из российских SOC, и дискуссионные доклады о возможности применения блокчейна при обмене информацией об угрозах. Завершит секцию открытая дискуссия со всеми ее участниками.
Модерировать секцию буду я, а свое участие в ней уже подтвердили:
ЗЫ. Программа SOC Forum уже финализирована и выложена на сайте.
Надо признать, что пока эта тема достаточно нова для российского потребителя, который часто путает SOC и SIEM, а программу управления инцидентами и соответствующие платформы IRP с требованиями по уведомлению регуляторов об обнаружении инцидентов ИБ в своей организации. Поэтому и темы, и вопросы, звучащие на SOC Forum пока носят базовый характер, так сказать «для начинающих» (что тоже важно). Однако это не значит, что помимо "азбуки" SOC, специалистов не интересуют продвинутые темы о применении в мониторинге ИБ Big Data, нейросетей, машинного обучения, блокчейна, когнитивных технологий, виртуальной реальности и других «модных словечек», о которых многие слышали, но не все знают о практике их применения. И не только вообще, но и в ИБ в частности. Именно поэтому в рамках SOC Forum было решено выделить целую секцию Future SOC и посвятить ее перспективным технологиям, которые только начинают применяться в современных центрах мониторинга ИБ. На секции будут и обзорные доклады о применении продвинутых аналитических методов в ИБ, и практические доклады для обмена опытом по использованию Big Data в деятельности одного из российских SOC, и дискуссионные доклады о возможности применения блокчейна при обмене информацией об угрозах. Завершит секцию открытая дискуссия со всеми ее участниками.
Модерировать секцию буду я, а свое участие в ней уже подтвердили:
- Эльман Бейбутов из IBM, который выступит с докладом "Когда все правила в SIEM уже написаны, наступает время для Advanced Security Analytics".
- Сергей Рублев из ГК Инфосекьюрити расскажет про "SOC в эпоху BigData" и реальный опыт применения Больших данных в деятельности SOC финансовой группы компаний.
- Алексей Качалиниз Сбербанка поделится своим видением "SOC 20..25: новые вызовы, новые горизонты" о том, какими свойствами будет/должен обладать центр мониторинга через 7-8 лет.
Я планировал также выступить в этой секции с докладом про применение блокчейна для обмена информацией об угрозах, достоинства и недостатки технологии в деятельности SOC.
Приходите, будет интересно!
ЗЫ. Программа SOC Forum уже финализирована и выложена на сайте.
8.11.17
Synopsys покупает Black Duck
2 ноября компания Synopsys объявила о намерении купить американского производителя средств анализа безопасности исходных кодов Black Duck Software. Стоимость сделки составила 560 миллионов долларов.
Словарь терминов, связанных с центрами мониторинга ИБ #socforum
"Дело было вечером, делать было нечего"... Так писал в своем стихотворении Сергей Михалков. Примерно также обстояли дела и в моем случае. Правда, дело было не вечером, а ночью, и делать мне было чего. Но я вдруг подумал: "А почему бы мне не сваять словарь терминов, связанных с деятельностью SOCов?" Сказано - сделано. Сваял. На все потратил часа три-четыре. И вот первая версия.
Разумеется, это не весь глоссарий. Я постарался включить в него наиболее активно используемые в русскоязычной и англозычной литературе термины, которые я постоянно вижу перед глазами. Понятно, что термины, связанные со стандартами в области обмена информацией об угрозах и инцидентах (например, я про них писал тут и тут), я включил далеко не все; достаточно было включить STIX, TAXII, TLP, OpenIOC и CybOX. Все остальное не так популярно.
Какой-то основы/оригинала у словаря нет. По сути - это надерганные из разных источников термины, которые я свел воедино и которые перевел на русский язык. К российским терминологическим стандартам (ФСТЭКовские ГОСТы и ЦБшные РСки) я обратился всего в 2-3-х случаях. Других терминов там просто нет, что и понятно. Тема SOCов относительно нова и ее еще просто не успели кодифицировать.
Качать свободно можно отсюда... (регистрация не требуется).
ЗЫ. Будут замечания и предложения - милости прошу. Пишите в комментариях - поправлю после набора критической массы (думаю, что к грядущему SOC Forum она как раз и наберется).
Разумеется, это не весь глоссарий. Я постарался включить в него наиболее активно используемые в русскоязычной и англозычной литературе термины, которые я постоянно вижу перед глазами. Понятно, что термины, связанные со стандартами в области обмена информацией об угрозах и инцидентах (например, я про них писал тут и тут), я включил далеко не все; достаточно было включить STIX, TAXII, TLP, OpenIOC и CybOX. Все остальное не так популярно.
Какой-то основы/оригинала у словаря нет. По сути - это надерганные из разных источников термины, которые я свел воедино и которые перевел на русский язык. К российским терминологическим стандартам (ФСТЭКовские ГОСТы и ЦБшные РСки) я обратился всего в 2-3-х случаях. Других терминов там просто нет, что и понятно. Тема SOCов относительно нова и ее еще просто не успели кодифицировать.
Качать свободно можно отсюда... (регистрация не требуется).
ЗЫ. Будут замечания и предложения - милости прошу. Пишите в комментариях - поправлю после набора критической массы (думаю, что к грядущему SOC Forum она как раз и наберется).
7.11.17
SOC, ориентированный на реальный мониторинг и на compliance #socforum
В последнее время наши регуляторы в лице ФСТЭК, ФСБ и Банка России выпустили целый ряд нормативных документов, которые вводят обязанность для попадающих под их действие организаций, заниматься мониторингом ИБ, реагированием на инциденты и управлением событиями безопасности. Это и 17/21/31-й приказы ФСТЭК, и новый ГОСТа ЦБ по базовому уровню защищенности финансовых организаций, и пока еще не опубликованные требования ГосСОПКА. А если еще наложить сюда действующие и планируемые требования по обязательному уведомлению об инцидентах, то складывается картина, что тема собственного или внешнего центра мониторинга кибербезопасности (SOC) как никогда лучше позволит выполнить действующие и будущие требования регуляторов.
Более того, наблюдая за тем, кто и как подходит к теме SOC, предположу, что соблазн скатиться к compliance-ориентированному SOC сейчас как никогда высок у наибольшей доли российских предприятий. Почему о SOCах заговорили именно сейчас? Что, раньше не было такой потребности? Была. Так почему сейчас? И почему все начинают строить SOCи, даже не имея нормального процесса управления журналами регистрации?
Попробовал для себя сформулировать признаки двух типов SOC - ориентированных на выполнение требований законодательства и на реальный мониторинг происходящего на предприятии в контексте кибербезопасности. У SOC в первом случае могут быть следующие признаки:
В данной цепочке мы, честно ответит себе пять раз "зачем", приходим к идее SOC, ориентированного на реальный мониторинг ИБ. А может быть и другая цепочка:
Тут, при том же исходном вопросе, мы видим совершенно иную цепочку рассждений, которая нас приводит к SOC, ориентированному на compliance. И строиться он будет именно исходя из этого (не как надо, а как написано в нормативке).
Более того, наблюдая за тем, кто и как подходит к теме SOC, предположу, что соблазн скатиться к compliance-ориентированному SOC сейчас как никогда высок у наибольшей доли российских предприятий. Почему о SOCах заговорили именно сейчас? Что, раньше не было такой потребности? Была. Так почему сейчас? И почему все начинают строить SOCи, даже не имея нормального процесса управления журналами регистрации?
Попробовал для себя сформулировать признаки двух типов SOC - ориентированных на выполнение требований законодательства и на реальный мониторинг происходящего на предприятии в контексте кибербезопасности. У SOC в первом случае могут быть следующие признаки:
- Фокусировка на мониторинге средств предотвращения угроз (МСЭ, AV, IPS, антиспам, контроль доступа и т.п.). Практически полное отсутствие поддержки систем настоящего мониторинга - NTA, CASB, EDR, UEBA и т.п.
- Инструментарий SOC живет по принципу “заблокировал и забыл” - никакого расследования инцидентов нет и в помине (тем более выстроенных процессов реагирования инцидентов). Также нет и аналитиков третьей линии, занимающихся threat hunting, и инструментария для обеспечения их работы (да того же YARA).
- Отсутствие playbook и написание правил корреляции по мере возникновения задачи, а не путем анализа use case (сценариев), которые должны лечь в основу ТЗ на построение SOC.
- Попытка охватить мониторингом все, что есть в организации, приводящая к перегрузке SIEM, наличии на первых порах сотен и тысяч тикетов в день.
- Ориентация на решения, подключенные к SOC, и технологии, обеспечивающие его работу. Полная забывчивость в отношении выстраивания процессов и их документирования (да-да, опять playbook/runbook), а также в отношении людей, составляющих ядро нормального SOC.
- Ориентация и следование стандартам и нормативным требованиям ("а как нам выполнить вот этт пункт приказа №17?").
- Никак не интегрированное с ИТ управление. Этот критерий поставил на последнее место, так как бывают такие ситуации, когда ИТ и ИБ живут как кошка с собакой и не дружат совсем. Но все-таки жить друг без друга они не могут и для достижения лучших результатов должны дружить, обмениваться данными и интегрировать свои решения по мониторингу (а то и вовсем иметь единую базу событий с разными процессами их анализа, расследования и реагирования).
- Ориентация не на события ИБ, а на инциденты, включая обработку единиц тикетов в день, проведения расследований, выстраивание процессов реагирования, наличие команды threat hunting (или контакты с внешними людьми) и т.п. Наличие нормального решения класса IRP (Incident Response Platform) или SOAR тоже является признаком хорошего SOC.
- Защита критичных активов, а не всего, что требует предварительного анализа и понимания существующего ландшафта используемых технологий, решений, процессов, узлов, пользователей, информации и т.п. Мы это все знаем?
- Ориентация на людей в SOC, а не на продукты. Игнорировать последние, конечно, не стоит, но и сильно уж полагаться на них тоже.
- Знание не только ЧТО [написано в стандартах и требованиях], но и КАК [это надо реализовать наиболее эффективно]. Это проверка/аудит/инспекция/аттестация будет проходить по принципу "есть/нет", а в реальной работе надо понимать, зачем вам та или иная функция и как ее можно решить наиболее оптимальным образом.
- Тесная интеграция с ИТ.
- Зачем нам SOC?
- Потому мы уже не справляемся с хаосом средств защиты и нам нужна упорядоченность.
- Зачем нам упорядоченность?
- Потому что нам нужно систематизировать все события безопасности, получаемые от средств защиты и приоритезировать их.
- Зачем нам систематизация и приоритезация?
- Потому что нам нужно реагировать в первую очередь только на самые важные инциденты.
- Зачем нам нужно реагировать сначала на важные инциденты?
- Потому что нам надо предотвратить ущерб для критичных активов предприятия.
В данной цепочке мы, честно ответит себе пять раз "зачем", приходим к идее SOC, ориентированного на реальный мониторинг ИБ. А может быть и другая цепочка:
- Зачем нам SOC?
- Потому что нам надо будет отправлять данные об инцидентах в ГосСОПКУ.
- Зачем нам туда направлять данные об инцидентах?
- Потому что скоро вступят в силу требования 187-ФЗ.
- Зачем нам выполнять требования 187-ФЗ?
- Потому что мы субъекты критической информационной инфраструктуры.
- Зачем нам выполнять требования, предъявляемые к субъектам КИИ?
- Потому что за их невыполнение грядет уголовная ответственность.
- Зачем нам выполнять эти требования?
- Потому что мы не хотим сесть в тюрьму на 6-10 лет лишения свободы.
Тут, при том же исходном вопросе, мы видим совершенно иную цепочку рассждений, которая нас приводит к SOC, ориентированному на compliance. И строиться он будет именно исходя из этого (не как надо, а как написано в нормативке).
Понятно, что это условное деление и реальный SOC может быть вообще гибридным - рассчитанным и на работу с регуляторами, и на реальный мониторинг ИБ. И фактор времени надо тоже учитывать. Сначала может быть вы строили SOC для compliance, а с течением времени перестроили его в нечто более эффективное для решения насущных задач (обратное движение тоже возможно, но реже). Просто обратите внимание, каких признаков у вас больше, примените метод "пяти зачем" (хотя у него тоже есть свои ограничения) и извлеките уроки.
3.11.17
Термин "периметр" только вредит информационной безопасности
Мы в области нашей являемся достаточно консервативными. Мы очень сильно зависим от авторитетов, от подходов, от продуктов и от терминов и определений, которые не меняются годами. Периметр информационной безопасности - это как раз тот термин, который, к сожалению, так устарел, что его использовать уже практически невозможно и даже вредно. Ситуация ухудшается тем, что мы даже до конца не знаем, что же такое периметр информационной безопасности.
Кто-то воспринимает периметр как точку соединения с Интернет. Как бы забавно это не звучало в контексте геометрии, в которой периметр это всё-таки замкнутая линия. Кто-то воспринимает периметр как линию которая очерчивает корпоративную или ведомственную сеть. Кто-то воспринимает периметр как набор устройств которые имеют выход в интернет.
Но каждое из этих определений очевидно имеет свои плюсы свои минусы и они не равнозначны. Как воспринимать ситуацию даже с таким казалось бы простым вариантом как промышленный сегмент, возможно даже физически изолированным от внешнего мира, если туда пришел представитель подрядный организации с ноутбуком который подключён через 3G четыре же модем к интернету. Появляется ли у нас здесь периметр или не появляется? А если мы посмотрим на ситуацию когда сотрудник с мобильным устройством подключается к облаку внешнему в котором хранятся конфиденциальные данные компании или работает приложение, обрабатывающее данные. Здесь есть периметр или нет? Ведь мы вообще можем использовать личное устройство сотрудника и чужую инфраструктуру облачного провайдера и кроме как информация от компании здесь нет вообще ничего.
Ну допустим у нас и мобильные устройства принадлежит компании, а облака принадлежит провайдеру. При этом максимум, что мы можем знать, это свой кусок этого облака, в котором мы располагаем наши сервера, наши приложения, наши данные. Но кто к ним имеет доступ извне со стороны облачного провайдера, со стороны других его клиентов? В такой ситуации вообще невозможно очертить периметр. А это означает, что как бы мы не хотели, но мы вынуждены изменять свои подходы к тому, что мы привыкли называть защитой периметра. Например, в компании Cisco мы исходим из того, что сотрудник компании может работать в любой момент времени из любой точки мира с любого устройства. В такой концепции, разумеется, не может быть периметра в общеупотребимом смысле и это заставляет совсем по-другому защищать, нет, не периметр, а подключение к Интернет! А вы готовы к новой реальности?
Утром того дня, когда я начинал писать эту заметку, я работал из дома, читая вебинар для одного из наших заказчиков, днём я приехал в офис и работал внутри нашей беспроводной корпоративной сети. Ближе к вечеру я пошёл на встречу в близлежащий Starbucks и также был подключён к нашей корпоративной сети уже через публичный хот-спот. Вечером я улетел в командировку и в процессе добирания до аэропорта на Аэроэкспрессе я работал через Wi-Fi в вагоне. В аэропорту я также подключился к корпоративной сети через местный WiFi, а в самолёте беспроводная сеть и выход в Интернет были предоставлены мне авиакомпанией. Всё время это были разные сети с разными требованиями и механизмами безопасности, но их объединяло одно - я всегда находился внутри своей корпоративной сети. Существует ли в такой динамической ситуации периметр и можно ли меня загнать в рамки традиционного периметра?
А почему термин "периметр ИБ" вреден? А потому, что он, будучи построен на устаревшей парадигме, создает чувство ложной защищенности. Давайте сделаем экскурс в историю. Какой была модель угроз в 800-1400 годах нашей эры? Если быстренько составить перечень актуальных угроз, то получится следующее:
Видите закономерность? Сначала периметровая концепция помогала - даже при меньшем числе обороняющихся (О) они могли с успехом противостоять атакующим (А). Артиллерия, автоматическое оружие, военно-воздушные силы изменили лицо войн. Замки стали сдавать свои позиции. Концепция периметра стала умирать. Самым, пожалуй, ярким примером такого провала стала линия Мажино, которая была просто обойдена немцами во время Второй мировой войны. 3 миллиарда французских франков было "выброшено в пропасть", как говорилось в известной советской комедии Гайдая.
В информационной безопасности все тоже самое. Старые подходы становятся бесполезными (это как рассчитывать на антивирус в борьбе с современным вредоносным ПО). Страны со слабой традиционной армией могут беспрепятственно выигрывать в кибервойне. Компании, успешные и добившиеся огромных успехов в реальном мире, проигрывают в киберпространстве. А все потому, что защита строится на старых подходах, которые перестали быть эффективными при современном развитии технологий. Их тоже пора выбросить в пропасть. Кстати, вспомните. В фильме "Кавказская пленница" Шурик ("нарушитель") смог проникнуть в защищенный высокими стенами дом, стоящий на скале, а Нина ("объект защиты") смогла покинуть периметр, несмотря на усилия Труса-Балбеса-Бывалого ("службы ИБ").
Что делать, спросите вы? Для начала просто понять слабость периметрового подхода. Этого уже немало. Во-вторых, надо защищать не только периметр, но и внутреннюю инфраструктуру, приложения и данные (а также облака и мобильные устройства, если они используются). Я про это писал 4 года назад, повторяться не буду. Но можно пойти еще дальше, внедрив концепцию "доверенного устройства" (мы ее у себя внутри Cisco так и назвали - "Trusted Device"), которая подразумевает, что центральным звеном защиты становится мобильное устройство сотрудника (ноутбук, смартфон, планшет и т.п.). Мы исходим из того, что это устройство может динамично перемещаться по разным местам (смотри выше пример с описанием того, как писалась эта заметка) и может не находиться под защитой периметрового МСЭ/IPS/ESA/WSA и др. Приняв это за основу, мы строим защиту вокруг именно устройства, делая его доверенным звеном, а всю размытую сеть Cisco - набором доверенных элементов. Но про эту концепцию я напишу как-нибудь отдельно.
Ну и в заключение минутка юмора. Классический мультфильм на тему незащищенного периметра. Я его еще лет 20 назад показывал на различных мероприятиях по ИБ:
 |
| Фрагмент лондонского Тауэра |
Но каждое из этих определений очевидно имеет свои плюсы свои минусы и они не равнозначны. Как воспринимать ситуацию даже с таким казалось бы простым вариантом как промышленный сегмент, возможно даже физически изолированным от внешнего мира, если туда пришел представитель подрядный организации с ноутбуком который подключён через 3G четыре же модем к интернету. Появляется ли у нас здесь периметр или не появляется? А если мы посмотрим на ситуацию когда сотрудник с мобильным устройством подключается к облаку внешнему в котором хранятся конфиденциальные данные компании или работает приложение, обрабатывающее данные. Здесь есть периметр или нет? Ведь мы вообще можем использовать личное устройство сотрудника и чужую инфраструктуру облачного провайдера и кроме как информация от компании здесь нет вообще ничего.
Ну допустим у нас и мобильные устройства принадлежит компании, а облака принадлежит провайдеру. При этом максимум, что мы можем знать, это свой кусок этого облака, в котором мы располагаем наши сервера, наши приложения, наши данные. Но кто к ним имеет доступ извне со стороны облачного провайдера, со стороны других его клиентов? В такой ситуации вообще невозможно очертить периметр. А это означает, что как бы мы не хотели, но мы вынуждены изменять свои подходы к тому, что мы привыкли называть защитой периметра. Например, в компании Cisco мы исходим из того, что сотрудник компании может работать в любой момент времени из любой точки мира с любого устройства. В такой концепции, разумеется, не может быть периметра в общеупотребимом смысле и это заставляет совсем по-другому защищать, нет, не периметр, а подключение к Интернет! А вы готовы к новой реальности?
Утром того дня, когда я начинал писать эту заметку, я работал из дома, читая вебинар для одного из наших заказчиков, днём я приехал в офис и работал внутри нашей беспроводной корпоративной сети. Ближе к вечеру я пошёл на встречу в близлежащий Starbucks и также был подключён к нашей корпоративной сети уже через публичный хот-спот. Вечером я улетел в командировку и в процессе добирания до аэропорта на Аэроэкспрессе я работал через Wi-Fi в вагоне. В аэропорту я также подключился к корпоративной сети через местный WiFi, а в самолёте беспроводная сеть и выход в Интернет были предоставлены мне авиакомпанией. Всё время это были разные сети с разными требованиями и механизмами безопасности, но их объединяло одно - я всегда находился внутри своей корпоративной сети. Существует ли в такой динамической ситуации периметр и можно ли меня загнать в рамки традиционного периметра?
А почему термин "периметр ИБ" вреден? А потому, что он, будучи построен на устаревшей парадигме, создает чувство ложной защищенности. Давайте сделаем экскурс в историю. Какой была модель угроз в 800-1400 годах нашей эры? Если быстренько составить перечень актуальных угроз, то получится следующее:
- разрушение стен или дверных проемов
- подкоп под стенами
- перелезание через стены
- осада
- предательство инсайдера
- дипломатия (угрозы, террор, психологические методы)
- биологическая война (заражение колодцев)
Поэтому и защита была соответствующей:
- 800-1000 годы нашей эры - фортификация становится стратегической задачей; активно начинают возводиться внешние стены и башни, окружающие объект защиты (дворец князя или иного властителя)
- 1000-1200 н.э. - утолщение стен, новые материалы (камень против дерева), здания с внутренней защитой
- 1400 - … - конец эры замков
Видите закономерность? Сначала периметровая концепция помогала - даже при меньшем числе обороняющихся (О) они могли с успехом противостоять атакующим (А). Артиллерия, автоматическое оружие, военно-воздушные силы изменили лицо войн. Замки стали сдавать свои позиции. Концепция периметра стала умирать. Самым, пожалуй, ярким примером такого провала стала линия Мажино, которая была просто обойдена немцами во время Второй мировой войны. 3 миллиарда французских франков было "выброшено в пропасть", как говорилось в известной советской комедии Гайдая.
 |
| Линия Мажино |
Что делать, спросите вы? Для начала просто понять слабость периметрового подхода. Этого уже немало. Во-вторых, надо защищать не только периметр, но и внутреннюю инфраструктуру, приложения и данные (а также облака и мобильные устройства, если они используются). Я про это писал 4 года назад, повторяться не буду. Но можно пойти еще дальше, внедрив концепцию "доверенного устройства" (мы ее у себя внутри Cisco так и назвали - "Trusted Device"), которая подразумевает, что центральным звеном защиты становится мобильное устройство сотрудника (ноутбук, смартфон, планшет и т.п.). Мы исходим из того, что это устройство может динамично перемещаться по разным местам (смотри выше пример с описанием того, как писалась эта заметка) и может не находиться под защитой периметрового МСЭ/IPS/ESA/WSA и др. Приняв это за основу, мы строим защиту вокруг именно устройства, делая его доверенным звеном, а всю размытую сеть Cisco - набором доверенных элементов. Но про эту концепцию я напишу как-нибудь отдельно.
Ну и в заключение минутка юмора. Классический мультфильм на тему незащищенного периметра. Я его еще лет 20 назад показывал на различных мероприятиях по ИБ:
2.11.17
Мониторинга много не бывает или зачем вам SOC, если у вас нет SIEM?
Осень выдается достаточно урожайной на мероприятия, посвященные теме мониторинга информационной безопасности. И на многих из них я часто слышу вопрос от коллег, который звучит очень просто: “Что должен уметь делать SOC?”. Как мне кажется, если такой вопрос возникает, то это значит, что компания еще не готова к SOC, так как в отличие от коробочных продуктов, сравниваемых по функциям/возможностям, SOC строится под конкретную компанию, под конкретную задачу. Поэтому бессмысленно спрашивать, что должен уметь делать SOC. Важнее понять, зачем он нужен и что будет делать, если компания решится инвестировать в него деньги. По этой же причине совершенно бестолково сравнивать SOCи между собой. Даже если они и построены на базе общих технологических решений, они могут решать совсем разные задачи, затачиваться под разные сценарии (use cases).
Посмотрите на эту картинку:
Она иллюстрирует упрощенную модель зрелости процесса управления журналами регистрации (log management). На каком уровне вы находитесь? Ответье честно сами себе. Если вы не достигли финального, пятого уровня (то, что находится в самом низу - это нулевой уровень), то о каком SOC может идти речь? Впору задуматься о SIEM, системе мониторинга ИБ. Кстати, неслучайно в нормативных документах той же ФСТЭК говорится о сборе событий безопасности, а не о мониторинге; это высший пилотаж, который могут потянуть далеко не все. Да, отсутствие NTA, EDR, UEBA, IRP (SOAR), CASB и других технологий тоже говорит, что вам пока рано думать о SOC, но управление логами - это основа основ мониторинга ИБ.
Я уже не раз писал, что в России не хватает фокусных мероприятий по тем или иным темам. Да, есть SOC Forum, целиком посвященный центрам мониторинга ИБ. Но в нем, по сути, мы перескочили через базу - через системы мониторинга (SIEM), без которых SOC не построишь. Хотя вон “Перспективный мониторинг” везде говорит, что у них в SOC нет SIEM, а все базируется на системе TIAS собственной разработки. Кстати, собственные разработки в области SIEM - это один из трендов российского рынка. Как раньше все разработчики создавали DLP-решения, так сейчас пришла пора для систем мониторинга, нужда в которых есть, а применять решения зарубежные боязно. Кто-то санкций боится, кому-то и вовсе запрещено применять иностранное, а кому-то нужно решение сертифицированное.
И вот на фоне этих обстоятельств и родилось еще одно мероприятие, которое пройдет 21-го ноября в Москве. Речь идет о научно-практической конференции “Мониторинг информационной безопасности - проблемы построения и эксплуатации”, проводимой ЦБИ. Когда я узнал об этом мероприятии (а меня пригласили модерировать одну из его секций), то у меня возник закономерный вопрос. 22-го же ноября проходит SOC Forum; не будет ли пересечения у этих двух событий, посвященных схожей теме? Но внимательно посмотрев на предварительную программу и пообщавшись с организаторами, я склоняюсь к мысли, что пересечений у конференции ЦБИ и SOC Forum будет немного.
Во-первых, мероприятие ЦБИ фокусируется на системах (SIEM), а не центрах (SOC) мониторинга. На нем будут говорить про масштабирование SIEM, работу с разными источниками данных, их нормализацию, оценку полноты данных и т.п. То есть речь пойдет одновременно и о научных аспектах, и о практических. Во-вторых, конференция “Мониторинг информационной безопасности” организована известным российским вендором со сложившейся клиентской базой. Поэтому предположу, что целевые аудитории у двух мероприятий будут разные. Кстати, это будет не совсем моновендорная конференция - в программе заявлены представители разных игроков рынка - Microsoft, РТ-Информа, Кода безопасности, НТЦ Вулкан, НИИАС, Infowatch, Крока, СолидЛаб, Газинформсервиса, ГНИВЦ ФНС и т.п. (это помимо ряда крупных заказчиков, которые будут делиться своим опытом применения систем мониторинга ИБ). В третьих, у мероприятия ЦБИ заявлено еще два интересных момента - объявление грантов на инновационные разработки в области мониторинга ИБ и сбор и формулирование предложений по совершенствованию нормативной базы в области мониторинга ИБ. Учитывая активную работу ЦБИ с отечественными регуляторами, может получиться донести до ФСТЭК, начавшей лицензирование SOC, и ФСБ, планирующей аккредитацию центров ГосСОПКИ, определенные правильные мысли. А если вспомнить, что на отдельных слайдах ФСТЭК в свое время проявлялась тема разработки требований по сертификации SIEM, то становится еще интереснее...
Так что мероприятие планирует быть интересным. Я буду модерировать секцию про стандарты и протоколы обмена информацией об инцидентах, угрозах, событиях безопасности и т.п., о чем я уже не раз писал. Учитывая, что у нас до сих пор еще не определены протоколы по обмену данными с ГосСОПКОЙ (а от этого зависит и взаимодействие финансовых организаций с ФинЦЕРТом), а в методических рекомендациях ФСБ по созданию ведомственных и корпоративных центров ГосСОПКА говорится, что формат описания инцидента определяется индивидуально с каждым, то дискуссия на конференции "Мониторинг информационной безопасности - проблемы построения и эксплуатации" обещает быть жаркой.
Посмотрите на эту картинку:
Я уже не раз писал, что в России не хватает фокусных мероприятий по тем или иным темам. Да, есть SOC Forum, целиком посвященный центрам мониторинга ИБ. Но в нем, по сути, мы перескочили через базу - через системы мониторинга (SIEM), без которых SOC не построишь. Хотя вон “Перспективный мониторинг” везде говорит, что у них в SOC нет SIEM, а все базируется на системе TIAS собственной разработки. Кстати, собственные разработки в области SIEM - это один из трендов российского рынка. Как раньше все разработчики создавали DLP-решения, так сейчас пришла пора для систем мониторинга, нужда в которых есть, а применять решения зарубежные боязно. Кто-то санкций боится, кому-то и вовсе запрещено применять иностранное, а кому-то нужно решение сертифицированное.
И вот на фоне этих обстоятельств и родилось еще одно мероприятие, которое пройдет 21-го ноября в Москве. Речь идет о научно-практической конференции “Мониторинг информационной безопасности - проблемы построения и эксплуатации”, проводимой ЦБИ. Когда я узнал об этом мероприятии (а меня пригласили модерировать одну из его секций), то у меня возник закономерный вопрос. 22-го же ноября проходит SOC Forum; не будет ли пересечения у этих двух событий, посвященных схожей теме? Но внимательно посмотрев на предварительную программу и пообщавшись с организаторами, я склоняюсь к мысли, что пересечений у конференции ЦБИ и SOC Forum будет немного.
Во-первых, мероприятие ЦБИ фокусируется на системах (SIEM), а не центрах (SOC) мониторинга. На нем будут говорить про масштабирование SIEM, работу с разными источниками данных, их нормализацию, оценку полноты данных и т.п. То есть речь пойдет одновременно и о научных аспектах, и о практических. Во-вторых, конференция “Мониторинг информационной безопасности” организована известным российским вендором со сложившейся клиентской базой. Поэтому предположу, что целевые аудитории у двух мероприятий будут разные. Кстати, это будет не совсем моновендорная конференция - в программе заявлены представители разных игроков рынка - Microsoft, РТ-Информа, Кода безопасности, НТЦ Вулкан, НИИАС, Infowatch, Крока, СолидЛаб, Газинформсервиса, ГНИВЦ ФНС и т.п. (это помимо ряда крупных заказчиков, которые будут делиться своим опытом применения систем мониторинга ИБ). В третьих, у мероприятия ЦБИ заявлено еще два интересных момента - объявление грантов на инновационные разработки в области мониторинга ИБ и сбор и формулирование предложений по совершенствованию нормативной базы в области мониторинга ИБ. Учитывая активную работу ЦБИ с отечественными регуляторами, может получиться донести до ФСТЭК, начавшей лицензирование SOC, и ФСБ, планирующей аккредитацию центров ГосСОПКИ, определенные правильные мысли. А если вспомнить, что на отдельных слайдах ФСТЭК в свое время проявлялась тема разработки требований по сертификации SIEM, то становится еще интереснее...
Так что мероприятие планирует быть интересным. Я буду модерировать секцию про стандарты и протоколы обмена информацией об инцидентах, угрозах, событиях безопасности и т.п., о чем я уже не раз писал. Учитывая, что у нас до сих пор еще не определены протоколы по обмену данными с ГосСОПКОЙ (а от этого зависит и взаимодействие финансовых организаций с ФинЦЕРТом), а в методических рекомендациях ФСБ по созданию ведомственных и корпоративных центров ГосСОПКА говорится, что формат описания инцидента определяется индивидуально с каждым, то дискуссия на конференции "Мониторинг информационной безопасности - проблемы построения и эксплуатации" обещает быть жаркой.
1.11.17
DNS как улика
Выступал на Russian Internet Week с рассказом про угрозы со стороны DNS и использование DNS как инструмента для проведения расследований инцидентов, защиты бренда, поиска сайтов-клонов и т.п. задач. Выкладываю презентацию:
Скачать ее можно с Dropbox. Кроме того, сегодня вышла и одноименная статья, которая по сути является текстовой версией (пусть и немного урезанной и менее иллюстрированной) этой презентации. Я ее писал для "ИТ Менеджера".
ЗЫ. Самое интересное, что описанные в презентации методы хакеров (тот же Fast Flux или DGA) могут использоваться пользователями для обхода блокировок анонимайзеров и VPN, закон о которых вступил в силу сегодня. Раньше ИТ-подходы находили свое отражение по ту сторону баррикад, а сейчас, похоже, будет обратный процесс.
Скачать ее можно с Dropbox. Кроме того, сегодня вышла и одноименная статья, которая по сути является текстовой версией (пусть и немного урезанной и менее иллюстрированной) этой презентации. Я ее писал для "ИТ Менеджера".
ЗЫ. Самое интересное, что описанные в презентации методы хакеров (тот же Fast Flux или DGA) могут использоваться пользователями для обхода блокировок анонимайзеров и VPN, закон о которых вступил в силу сегодня. Раньше ИТ-подходы находили свое отражение по ту сторону баррикад, а сейчас, похоже, будет обратный процесс.
Подписаться на:
Сообщения (Atom)
