Намедни читал сообщение от широкоизвестного производителя решений безопасности о том, как он изобрел новую революционную платформу для защиты технологических сетей (для упрощения далее буду писать "АСУТП"). Новость содержала ссылку на whitepaper из нескольких страниц, где можно узнать по новинке более детально. Я внимательно ознакомился с этой белобумагой и, поскольку подобные публикации неоднократно читал и у других вендоров, поймал себя на мысли, которой хочется поделиться.
Я заметил, что более двух третих, а то трех четвертей описаний достоинств решений для защиты АСУТП посвящено тому, как они эффективно борятся с вирусами, шифровальщиками, червями и прочей ерундой, полностью эквивалентной тому, от чего защищают классические системы безопасности, применяемые для офисных сетей. Да, там есть слова про понимание технологических протоколов, но этого мало и крайне-крайне редко приводятся описания бизнес-кейсов как это используется и что дает. Это неправильно.
Очевидно, что классические системы безопасности за годы господства на рынке достигли достаточной зрелости, и это позволяет нам уверенно утверждать, что они крайне эффективны от угроз для которых предназначены, и изобретать здесь вилосипед, который "по-другому" будет бороться с сетевыми атаками, червями, шифровальщиками и вирусами, не надо. Получается, что для защиты АСУТП, во-первых, требуется весь стек этих классических инфраструктурных систем безопасности, ибо АСУТП, как и офис, - тоже сеть, инфраструктура.
С другой стороны, не следует забывать АСУТП - это уже уровень приложения, автоматизирующего тот или иной бизнес-процесс. На этом уровне уже свои риски и сценарии атак (если быть точным, то в конечном счете риски одни и те же, и они бизнесовые, но на разных уровнях они выглядят по-разному, поэтому различны и подходы к их обнаружению и управлению), следовательно, свои модели нарушителей, следовательно, требуется реализация своих контролей безопасности. Риски информационной безопасности приложений всегда тесно связаны с рисками бизнес-процессов, ими автоматизируемых, правильно считать, что риски АСУТП - это проектция рисков бизнес-процессов на уровень приложения. Для какого-нибудь завода важна непрерывность технологического процесса, недопущение останова; контроль каких-то параметров работы оборудования для недопущение техногенной катастрофы; если сырье и/или готовая продукция ликвидны необходимо недопускать хищений, и т.п. Для розничной торговли на первый план выходит мошенничество (ну, безусловно простой тоже недопустим, ибо, например, для любой АЗС, точно понятна стоимость ее простоя в определенное время просто на основании статистики прошлой работы), причем здесь могут быть задействованы не только рядовые операторы POS-терминалов, но и обслуживающие ИТ-подразделения. Использование пластиковых карт для оплаты и различные программы лояльности добавляют новые риски и модели нарушителя. И так далее. В разных сетях автоматизации может быть по-разному. Важно понимать, что на уровне приложения уже следует заниматься снижением бизнес-рисков, а с вирусами и пр. стандартными вещами прекрасно справятся классические системы ИБ, от которых, как указано выше, не следует отказываться.
На практике можно делать это следующим образом: проанализировать бизнес-процессы, понять схемы мошенничества или любой другой вредоносной активности, несущей материальные риски, придумать как на уровне АСУТП эти риски адресовать; и здесь применяется концептуально тот же подход : предотвратить, если технически возможно, а если невозможно - достоверно обнаружить. Под материальным риском здесь понимаются те, что ассоциированы с реальным ущербом, никогда не следует охотиться на ведьм и приоритезироваться всегда в те 20%, которые дадут 80% результата. А достоверно обнаружить означает, что на уровне приложения и инфраструктуры риски, связанные с умышленным нарушением целостности логов, на основании которых мы судим о происходящем и фиксируем инциденты, адекватно адресованы. Security Operations Center здесь также может (и должен!) быть эффективным и результативным контролем безопасности, но в отличии от классического SOC, работающего, обычно, на уровне инфраструктуры и сражающегося в конечном счете с инструментами: сетевыми атаками, различными видами ВПО, этот, технологический SOC, будет искать мошенничество с пластиковыми картами и картами лояльности, нелегитимные изменения параметров технологического процесса, нарушение целостности метрологических систем, злоупотребления доступом и служебным положением и пр. сценарии атак и модели нарушителей, разработанные при анализе защищаемых бизнес-процессов и проектировании контролей безопасности. Организационные подходы к построению технологического SOC такие же как и в случае SOC для борьбы с инфраструктурными угрозами, но различна специализация персонала, который должен хорошо разбираться в защищаемом бизнес-процессе, чтобы корректно интерпретировать выявленные аномалии, говоря заумно, но короче, - правильно делать триаж.
Мы всегда говорим об эшелонированном подходе к безопасности, имея в виду, что у нас снаружи - периметр, внутри - сегментация, и сами конечные устройства защищены. Однако, эшелонированный подход применим абсолютно по всем перспективам. Как отмечалось выше, мы можем отступать по реакции , можем комбинировать подходы и технологии обнаружения , и пр., но, кроме перечисленного, мы можем применять весь стек контролей как на уровне инфраструктуры, так и на уровне приложений, и даже выше - организационно непосредственно на уровне бизнес-процессов, уже за рамками ИТ. Например, на уровне бизнес-процесса мы можем организовать SOD , когда точку розничной продажи поддерживают ИТ из другого региона и ротировать группу поддержки каждый год - это снизит риск преступного сговора работников магазина с подразделениями ИТ, обслуживающим POS-терминалы и бэк-офисное ПО. На уровне приложения мы можем организовать централизованный сбор криптографически защищенноых логов обо всех действиях персонала магазина, настроить профилирование и обнаружение аномалий, а также конкретных сценариев мошенничества в автоматическом режиме с последующей валидацией на линиях SOC - это позволит обнаруживать различного рода вредоносные действия и злоупотреблеия. На уровне инфраструктуры мы можем обеспечить полный контроль всех запускаемых приложений и используемых потенциальными атакующими техник - также в автоматическом режиме с расследованием аналитиком SOC.
Намеренно не хотел в посте ссылаться на какой-то личный опыт, чтобы никого и ничего не запалить, получилось несколько размыто, поэтому, хотя бы, подведу итоги.
1. АСУТП также крутится на инфраструктуре, поэтому классические системы инфраструктурной безопасности там также должны применяться.
2. Системы безопасности АСУТП работают на уровне приложения, поэтому, помимо контролей в инфраструктуре, они должны реализовывать меры на уровне приложений и прикладных протоколов.
2.5. Для вендоров, выросших из инфраструктурной безопасности и решивших подняться на уровень приложения, логичным кажется модульный подход, когда безопасность АСУТП (и любых других приложений, коими заинтересуется производитель) обеспечивается дополнительными компонентами к системам инфраструктурной безопасности. При таком подходе не теряется вся накопленная практика в области инфраструктуры, и продукт наделяется новыми "способностями" по обнаружению на уровне приложений. В конечном счете это разумно еще и потому, что есть масса приложений и разобр каждого из них в отдельном модуле позволит конечному заказчику, как конструктор, собирать функционал, релевантный ему.
3. Весь комплекс контролей безопасности, реализуемых на уровне инфраструктуры, как технических (например, анализ аномалий в протоколах), так и организационных (как, например, операционные сервисы безопасности: мониторнг и реагирование на инцидент, анализ соответствия требованиям и управление уязвимостями и т.п.), применим и на прикладном уровне, но с учетом соответствующей специфики. Это и есть еще одна перспектива эшелонированного подхода, когда один и тот же потенциальный сценарий атаки мы ловим на разных уровнях абстракции, используя разные подходы.
3.5 Технологический SOC - необходимое и абсолютно правильное явление, позволяющее адресовать риски на уровне бизнес-процессов посредством их обнаружения и расследования с помощью техничеких контролей, реализованных в специализированных приложениях и на инфраструктуре.
3.6 Технологический SOC может объединяться с классическим инфраструктрным SOC, например, как линия эскалации на экспертов в предметной области. Поскольку предметных областей много, как много и бизнес-процессов, и средств их автоматизации, - таких экспертных линий эскалации вполне может быть также много.
Я заметил, что более двух третих, а то трех четвертей описаний достоинств решений для защиты АСУТП посвящено тому, как они эффективно борятся с вирусами, шифровальщиками, червями и прочей ерундой, полностью эквивалентной тому, от чего защищают классические системы безопасности, применяемые для офисных сетей. Да, там есть слова про понимание технологических протоколов, но этого мало и крайне-крайне редко приводятся описания бизнес-кейсов как это используется и что дает. Это неправильно.
Очевидно, что классические системы безопасности за годы господства на рынке достигли достаточной зрелости, и это позволяет нам уверенно утверждать, что они крайне эффективны от угроз для которых предназначены, и изобретать здесь вилосипед, который "по-другому" будет бороться с сетевыми атаками, червями, шифровальщиками и вирусами, не надо. Получается, что для защиты АСУТП, во-первых, требуется весь стек этих классических инфраструктурных систем безопасности, ибо АСУТП, как и офис, - тоже сеть, инфраструктура.
С другой стороны, не следует забывать АСУТП - это уже уровень приложения, автоматизирующего тот или иной бизнес-процесс. На этом уровне уже свои риски и сценарии атак (если быть точным, то в конечном счете риски одни и те же, и они бизнесовые, но на разных уровнях они выглядят по-разному, поэтому различны и подходы к их обнаружению и управлению), следовательно, свои модели нарушителей, следовательно, требуется реализация своих контролей безопасности. Риски информационной безопасности приложений всегда тесно связаны с рисками бизнес-процессов, ими автоматизируемых, правильно считать, что риски АСУТП - это проектция рисков бизнес-процессов на уровень приложения. Для какого-нибудь завода важна непрерывность технологического процесса, недопущение останова; контроль каких-то параметров работы оборудования для недопущение техногенной катастрофы; если сырье и/или готовая продукция ликвидны необходимо недопускать хищений, и т.п. Для розничной торговли на первый план выходит мошенничество (ну, безусловно простой тоже недопустим, ибо, например, для любой АЗС, точно понятна стоимость ее простоя в определенное время просто на основании статистики прошлой работы), причем здесь могут быть задействованы не только рядовые операторы POS-терминалов, но и обслуживающие ИТ-подразделения. Использование пластиковых карт для оплаты и различные программы лояльности добавляют новые риски и модели нарушителя. И так далее. В разных сетях автоматизации может быть по-разному. Важно понимать, что на уровне приложения уже следует заниматься снижением бизнес-рисков, а с вирусами и пр. стандартными вещами прекрасно справятся классические системы ИБ, от которых, как указано выше, не следует отказываться.
На практике можно делать это следующим образом: проанализировать бизнес-процессы, понять схемы мошенничества или любой другой вредоносной активности, несущей материальные риски, придумать как на уровне АСУТП эти риски адресовать; и здесь применяется концептуально тот же подход : предотвратить, если технически возможно, а если невозможно - достоверно обнаружить. Под материальным риском здесь понимаются те, что ассоциированы с реальным ущербом, никогда не следует охотиться на ведьм и приоритезироваться всегда в те 20%, которые дадут 80% результата. А достоверно обнаружить означает, что на уровне приложения и инфраструктуры риски, связанные с умышленным нарушением целостности логов, на основании которых мы судим о происходящем и фиксируем инциденты, адекватно адресованы. Security Operations Center здесь также может (и должен!) быть эффективным и результативным контролем безопасности, но в отличии от классического SOC, работающего, обычно, на уровне инфраструктуры и сражающегося в конечном счете с инструментами: сетевыми атаками, различными видами ВПО, этот, технологический SOC, будет искать мошенничество с пластиковыми картами и картами лояльности, нелегитимные изменения параметров технологического процесса, нарушение целостности метрологических систем, злоупотребления доступом и служебным положением и пр. сценарии атак и модели нарушителей, разработанные при анализе защищаемых бизнес-процессов и проектировании контролей безопасности. Организационные подходы к построению технологического SOC такие же как и в случае SOC для борьбы с инфраструктурными угрозами, но различна специализация персонала, который должен хорошо разбираться в защищаемом бизнес-процессе, чтобы корректно интерпретировать выявленные аномалии, говоря заумно, но короче, - правильно делать триаж.
Мы всегда говорим об эшелонированном подходе к безопасности, имея в виду, что у нас снаружи - периметр, внутри - сегментация, и сами конечные устройства защищены. Однако, эшелонированный подход применим абсолютно по всем перспективам. Как отмечалось выше, мы можем отступать по реакции , можем комбинировать подходы и технологии обнаружения , и пр., но, кроме перечисленного, мы можем применять весь стек контролей как на уровне инфраструктуры, так и на уровне приложений, и даже выше - организационно непосредственно на уровне бизнес-процессов, уже за рамками ИТ. Например, на уровне бизнес-процесса мы можем организовать SOD , когда точку розничной продажи поддерживают ИТ из другого региона и ротировать группу поддержки каждый год - это снизит риск преступного сговора работников магазина с подразделениями ИТ, обслуживающим POS-терминалы и бэк-офисное ПО. На уровне приложения мы можем организовать централизованный сбор криптографически защищенноых логов обо всех действиях персонала магазина, настроить профилирование и обнаружение аномалий, а также конкретных сценариев мошенничества в автоматическом режиме с последующей валидацией на линиях SOC - это позволит обнаруживать различного рода вредоносные действия и злоупотреблеия. На уровне инфраструктуры мы можем обеспечить полный контроль всех запускаемых приложений и используемых потенциальными атакующими техник - также в автоматическом режиме с расследованием аналитиком SOC.
Намеренно не хотел в посте ссылаться на какой-то личный опыт, чтобы никого и ничего не запалить, получилось несколько размыто, поэтому, хотя бы, подведу итоги.
1. АСУТП также крутится на инфраструктуре, поэтому классические системы инфраструктурной безопасности там также должны применяться.
2. Системы безопасности АСУТП работают на уровне приложения, поэтому, помимо контролей в инфраструктуре, они должны реализовывать меры на уровне приложений и прикладных протоколов.
2.5. Для вендоров, выросших из инфраструктурной безопасности и решивших подняться на уровень приложения, логичным кажется модульный подход, когда безопасность АСУТП (и любых других приложений, коими заинтересуется производитель) обеспечивается дополнительными компонентами к системам инфраструктурной безопасности. При таком подходе не теряется вся накопленная практика в области инфраструктуры, и продукт наделяется новыми "способностями" по обнаружению на уровне приложений. В конечном счете это разумно еще и потому, что есть масса приложений и разобр каждого из них в отдельном модуле позволит конечному заказчику, как конструктор, собирать функционал, релевантный ему.
3. Весь комплекс контролей безопасности, реализуемых на уровне инфраструктуры, как технических (например, анализ аномалий в протоколах), так и организационных (как, например, операционные сервисы безопасности: мониторнг и реагирование на инцидент, анализ соответствия требованиям и управление уязвимостями и т.п.), применим и на прикладном уровне, но с учетом соответствующей специфики. Это и есть еще одна перспектива эшелонированного подхода, когда один и тот же потенциальный сценарий атаки мы ловим на разных уровнях абстракции, используя разные подходы.
3.5 Технологический SOC - необходимое и абсолютно правильное явление, позволяющее адресовать риски на уровне бизнес-процессов посредством их обнаружения и расследования с помощью техничеких контролей, реализованных в специализированных приложениях и на инфраструктуре.
3.6 Технологический SOC может объединяться с классическим инфраструктрным SOC, например, как линия эскалации на экспертов в предметной области. Поскольку предметных областей много, как много и бизнес-процессов, и средств их автоматизации, - таких экспертных линий эскалации вполне может быть также много.
