Как стать автором
Обновить

Без хаоса и паники: Как мы обеспечиваем безопасность промышленных устройств

Время на прочтение 14 мин
Количество просмотров 18K
Привет, Хабр! Меня зовут Иван Люкшин, я руковожу отделом разработки продукта для защиты критической инфраструктуры Kaspersky Industrial CyberSecurity (KICS) for Networks. Наш продукт анализирует трафик в поисках атак, аномалий и информации о сетевых активах на предприятиях, где есть промышленная автоматизация. Ежедневно мы сталкиваемся со множеством нестандартных задач, и сегодня я расскажу, почему это норма для нас. Спойлер: для тех, кто заинтересуется направлением, в конце статьи несколько вопросов из числа тех, что мы задаём на собеседованиях.

Я работаю на проекте KICS с конца 2012 года. Пришёл в поисках чего-то нового из команды флагманского продукта. Начинал в статусе старшего разработчика C++, потом вырос до тимлида и в итоге стал руководителем проекта. Сейчас в команде KICS for Networks трудится около 60 человек, хотя непосредственно наш отдел немного меньше. На работе мы препарируем протоколы, разрабатываем способы детектирования аномалий, визуализируем и храним кучу данных, оптимизируем свой код, чтобы безопасность не требовала космически дорогого железа. И это дает свои результаты: у нас множество внедрений по стране и миру, за каждым из которых своя история.

Защищать устройства или среду — вот в чём вопрос

Отрасль безопасности систем формируется у нас на глазах. Мы проходим интересный период, когда ещё нет общих практик и тест-сетов, как в антивирусах. Даже продукты разных вендоров пока что сравниваются «в лоб» — на моделирующих угрозы стендах в ходе встречи «хакеров» и «защитников».
Пока что ни у кого нет ответа на главный вопрос: как именно подходить к безопасности в этой сфере? Одни компании считают, что нужно обеспечивать защиту конечных устройств. Другие предпочитают следить за безопасностью среды передачи — в зависимости от того, в чём они были сильны ранее. К существующим решениям просто добавляется индустриальная специфика.
Мы в «Лаборатории Касперского» исходим из того, что главное не утечка данных, а непрерывность и безопасность технологических процессов АСУ ТП. Поэтому мы мониторим сетевую активность систем управления и автоматизации, следим за параметрами технологического процесса и аномалиями в среде передачи: за нестандартными паттернами трафика, появлением или исчезновением пакетов для определённых IP-адресов — любыми изменениями, которые могут свидетельствовать о посторонней активности в технологическом процессе.
Ещё нюанс: промышленная автоматизация зачастую построена на технологиях десятилетней давности и может сломаться от вируса, про который уже успели позабыть. Какой-нибудь conflicker или даже ping of death может сломать электроподстанцию или систему очистки воды, остановить конвейер. А такое заражение — это нарушение непрерывности процессов, недополученная прибыль и расходы на восстановление систем, что может повлиять на жизни многих людей.
Атаки на технологические процессы способны годами делать своё чёрное дело и незаметно разрушать промышленную систему, например так, как это делал Stuxnet. Но могут и моментально посеять хаос и панику, отключив электроэнергию у множества пользователей, как это задумывалось в Industroyer. Такие масштабные атаки — это действительно не массовая история. Но это не значит, что с проблемами не сталкиваются предприятия поменьше. Просто о них не всегда говорят, в том числе из-за возможных проблем с репутацией.
Stuxnet и для нас стал триггером: мы поняли, что оптимальная стратегия — сосредоточиться на контроле технологического процесса. Так что в ходе внедрения мы даём заказчику возможность построить контур безопасности: задать правила, что он считает хорошим, а что — плохим. После этого контролируем соблюдение этих правил.
В общих словах процесс выглядит просто. Сложность, как обычно, в деталях. И вот тут начинается самая интересная работа.

Нет типовых решений, есть инженерный поиск каждый день

Принципиальное отличие промышленности от бизнеса в других сферах в том, что здесь нет и не может быть типовых решений, которые поставляются в формате «коробки». В любом случае надо подстраиваться под имеющееся у заказчика оборудование и технологические процессы. Даже у двух условно одинаковых сталелитейных гигантов всё будет организовано по-разному — как минимум каждое предприятие находится на своём уровне зрелости автоматизации. Поэтому развернуть стандартную конфигурацию на деле не получится.
Мы работаем с тем оборудованием, которое установлено у заказчика, а оно очень неоднородно. Это могут быть и самые современные устройства, и те, что в строю уже 20 лет. И проблема здесь не столько в возрасте, сколько в разношёрстности подходов к вопросам безопасности.
У каждого производителя свой жизненный цикл инструментов автоматизации, а поэтому все эти железки находятся на разных этапах понимания ландшафта киберугроз — они построены в соответствии с теми нормами, которые были актуальны на момент их выпуска. В итоге инфраструктура часто бывает рассинхронизирована. Для нас это часто оборачивается нетривиальными задачами при внедрении.
Например, у заказчика установлено устройство, выпущенное в тот период, когда считалось обязательным шифровать канал. А из-за шифрованного канала между устройствами и АСУ ТП нам приходится либо исключать этот трафик из анализа, либо ставить дополнительное железо, которое будет расшифровывать канал. Это прямые затраты для клиента и усложнение архитектуры решения для интегратора (внедряющего наше решение), чего допускать не хотелось бы. И мы начинаем думать, как это обойти: оптимизировать парсинг трафика, отключить шифрование или применить какой-то ещё подход. Инженерный поиск каждый день!
Ещё один важный момент: на предприятии далеко не всегда есть документация на то, что было однажды внедрено. Предположим, работал интегратор, который до сих пор обеспечивает поддержку, но вся информация о системе находится на его стороне. Так что для настройки анализа трафика нам приходится подключать третью сторону к общению.
А ещё бывает, что на объекте поработало несколько интеграторов и уже никто не знает, что, когда и куда подключено. Это классическая история, когда заказчик уверен, что у него вся сеть изолирована и не имеет доступа к интернету, а после развертывания KICS оказывается, что туда давным-давно был прокинут доступ к интернету и заказчики приходят со своими ноутбуками.

Гайды по масштабированию вместо коробочных продуктов

Казалось бы, в описанных условиях к каждому внедрению мы должны подходить «с чистого листа». Но, исходя из уже реализованных проектов, мы можем обобщить и предсказать некоторые вещи.
Конечно, мы работаем с чувствительной для заказчика информацией, поэтому не можем передать успешный кейс одного клиента другому. Но, опираясь на опыт наших специалистов по внедрению, мы ведём работу с интеграторами, чтобы они знали, как учитывать нужды безопасности в своих проектах — от схем и регламентов до места в серверных шкафах и кабель-каналах.
Эта работа упрощает последующую эксплуатацию продукта на всех жизненных фазах: и при обучении, и в режиме мониторинга. Например, при остановке какого-нибудь конвейера компании не приходится отбиваться от множества ложных сообщений об аномалиях в передаваемом трафике. Если же инфраструктура предприятия при автоматизации ИБ-процессов не учитывала, интеграторы смогут её модернизировать и настроить необходимые процедуры, а мы помогаем в этом процессе.
Параллельно мы работаем с производителями железа, чтобы убедиться в совместимости с различными устройствами. KICS for Networks не влияет на взаимодействия в сети — система получает копию трафика, но для тех же антивирусов нужны вычислительные мощности, а значит, и сертификация производителя (мы же не хотим, чтобы антивирусные проверки влияли на технологические процессы).

Кто и как всем этим занимается

В «Лаборатории Касперского» есть глобальная техническая поддержка, которая устроена классическим образом — разделена на несколько линий. Мы в команде разработки входим в третью линию, куда обращаются в тех случаях, когда первая и вторая линия не разобрались в проблеме. И, решая проблему, нам зачастую надо повторить инфраструктуру клиента. Обычно по итогам обращений приходится что-то фиксить или менять в будущих версиях.
Глобально работа нашей команды не отличается от разработки в других компаниях. Мы пишем код. У нас есть ограничения по стоимости железа под развёртывание продукта (иначе мы, как производитель софта, вынуждены будем весь свой доход передать производителю железа), а это целый пласт проблем, связанных с оптимизацией.
Кстати, наш продукт на Linux, поскольку на нём изначально проще конфигурировать разные сети. В Windows без драйверов такие задачи решить было бы сложно, а нам в клиентской поддержке иногда нужно строить довольно экзотические стенды.
У нас стандартный стек технологий. Фронтенд на Angular, бэкенд на ASP.NET (C#). Это довольно распространённые инструменты, поэтому в поисках коллег мы ориентируемся в том числе на софт-скиллы. Нам важна целеустремлённость, самостоятельность и умение работать в команде, а также дух, соответствующий общему настрою команды. И не менее важно, чтобы человеку было интересно работать с теми технологиями, которые мы создаём. А развернуться есть где.
Для работы у нас нужны знания в различных областях. Полезно понимать сетевую специфику, ландшафт угроз, которые в принципе могут существовать, да и знания протоколов не лишние. Мы работаем не только с современными протоколами — иногда приходится работать и с теми, которые существенно просаживают производительность при парсинге, потому что нам нужно разбирать такие протоколы полностью. Однако мы не требуем этих знаний на входе в команду — всем деталям научим сами.
У нас можно по классике безвылазно работать в офисе, а можно иногда ездить по объектам (ведь не все клиенты дают удалённый доступ в свою инфраструктуру). Плюс у нас есть свой мини-завод без производства, но с оборудованием, где мы можем тестировать гипотезы.
Подразделение KICS работает по скраму двухнедельными спринтами. Реализация не совсем каноническая, но, как и все, мы ежедневно встречаемся на статус-митингах и проводим ревью итераций, когда мы показываем результаты, стараясь максимально визуализировать то, что мы создаём. Есть и ретроспектива, когда мы рефлексируем и пытаемся улучшить не только продукт, но и наши собственные процессы.
Лет 7 назад в компании начали внедряться общепринятые практики разработки — статический и динамический анализ кода, фаззинг и т. п. Все эти процессы объединяются под названием Secure Development Lifecycle и в нашем случае неизбежны, поскольку продукт имеет сертификацию ФСТЭК и её надо получать заново для каждой следующей версии. Проще один раз выстроить внутренние процессы под их требования, чем каждый раз мучиться при подаче заявки на очередную сертификацию. Правда, внутри мы используем немного иные инструменты, нежели применяет ФСТЭК, но это уже детали.
Кстати, на этом влияние ФСТЭК на деятельность разработчиков заканчивается. Мы не занимаемся подачей заявок, только готовим техническую документацию. За всё остальное отвечает отдел сертификации.
Мы стараемся делать так, чтобы в команде было интересно работать. Порой это получается само собой, поскольку у нас разносторонний спектр задач — от баз данных до разбора трафика. И мы специально эти задачи не ограничиваем.
Несмотря на то что в разработке мы стараемся использовать свежие инструменты и стандарты, у нас вариативная подборка технологий. Иногда в работе необходимы знания, которые, как кажется, получены случайно. А если обычная жизнь не подкидывает интересных задач, мы экспериментируем: тестировщики и аналитики могут писать код (если у них к этому лежит душа), а административное деление команд вполне может нарушаться под разработку определённой важной фичи и т. п. В целом мы любим экспериментировать.

А что в будущем?

Сегодня решения в области безопасности индустриальных устройств идеологически сближаются. И производители, ориентированные на защиту устройств, и те, кто обеспечивали безопасность сети, формируют комплексные инструменты, подтягивая недостающий функционал или лицензируя для этого сторонние решения.
Мне кажется, мы уже на финишной прямой появления стандартных подходов в области индустриальной кибербезопасности и фактически сами влияем на их облик. В следующем году ждём появления квадранта Gartner по этому сегменту, который и опишет его ландшафт — появится чёткое понимание, что собой представляет рынок.
Возможно, в следующем году также появится методика сравнения решений. Уже существует целая серия международных стандартов IEC62443, принятых за последние 10 лет (многие из них выходили совсем недавно — в 2018—2019 годах) и есть независимые исследователи, готовые их обобщить. Как только отрасль примет чью-то методику сравнения, начнутся большие гонки производителей решений за пальму первенства: кто защитит промышленные устройства лучше?
Хотите стать частью нашей команды и поучаствовать в этой гонке? Мы расширяемся и ищем тех, кому небезразлична тематика промышленной безопасности.
А чтобы вы могли оценить, чем придётся заниматься, мы подготовили несколько вопросов из числа тех, что задают на собеседованиях.

Вопросы по Angular

Вопрос 1
В приложении используется компонент, получающий часть настроек через инжектируемый сервис
export class TestInjectComponent {
  constructor(private settings: ISettings) { }
...
Компонент используется в разных местах приложения, например так:
<app-nav>
  <app-test-inject></app-test-inject>
</app-nav>
<app-main>
  <app-test-inject></app-test-inject>
</app-main>
При этом требуется использовать разные настройки, предоставляемые IService в экземпляре app-test-inject внутри app-nav и app-main. Как лучше это реализовать?
Вопрос 2
В приложении используются компоненты со следующими шаблонами:
main-page.component.html
<app-container>
  <app-container-item *ngFor="let item of items" [value]="item">
  </app-container-item>
</app-container>
container.component.html
<ng-content></ng-content> 
container-item.component.html
{{ value }}
Логика работы приложения требует наличия в коде компонента Container ссылок на экземпляры компонентов ContainerItem. Предложите способы получения таких ссылок.
Вопрос 3
В приложении реализован компонент, отображающий примечание и умеющий его скрывать по клику на кнопку. Операция сокрытия должна быть однократной, не требуется заново отображать элемент, после того как он был скрыт. Ниже показана реализация:
test-component.ts
import { Component } from '@angular/core';
@Component({
  selector: 'app-test',
  templateUrl: './test.component.html',
  styleUrls: ['./test.component.scss']
})
export class TestComponent {
  public value = 'Lorem ipsum dolor sit amet';
  public hideValue(): void {
	document.querySelector('.description').remove();
  }
}
test-component.html
<button (click)="hideValue()">hide value</button>
<app-container-item class="description" [value]="value"></app-container-item>
Компонент исправно работает. Могут ли быть проблемы с такой реализацией? Если да, то как лучше изменить код?
Вопрос 4
В приложении реализован дашборд. Клиенты размещают на нём очень большое количество (2000+) виджетов. Каждый виджет раз в секунду запрашивает у сервера данные, которые он должен отобразить. Данные для большинства виджетов состоят из двух полей number + string, некоторые виджеты запрашивают коллекцию объектов с полями name + status. Клиенты жалуются на то, что приложение тормозит — обновление данных в виджетах регулярно занимает несколько секунд. Разработчики не имеют доступа к сети, в которой развёрнуто приложение.
  • Назовите возможные причины медленной работы приложения и предложите способы их устранения.
  • Какие данные можно запросить у клиента для диагностики наблюдаемой медленной скорости работы?
Вопрос 5
Angular-приложение должно позволять администратору писать JavaScript-код, встраиваемый в главную страницу сайта. Пример решаемой таким образом задачи: получение данных о новых обнаруженных вирусах и отображение виджета со сводкой, отображение счётчиков и пр.
Какие проблемы / уязвимости могут возникнуть при таком подходе? Как лучше подойти к решению подобной задачи? Как минимизировать риски, если полностью отказаться от внедрения скриптов невозможно?

Вопросы по DotNet и БД

Вопрос 1
Приложение реализует работу с картой города. Карта содержит только один вид объектов — дома. Дома представлены в виде многоугольников. Предложите схему БД для хранения следующей информации о домах:
  • адрес;
  • координаты вершин.
Вопрос 2
Пользователь просматривает карту из п. 1 в приложении. Нужно реализовать rest api метод получения данных о домах, которые требуется отрисовать на экране пользователя. Аргументы запроса — координаты прямоугольной области, соответствующей положению окна пользователя на карте (x, y, width, height). Для работы с БД можно использовать SQL-запросы или EF.
Вопрос 3
Разрабатывается сервис для обработки потока файлов. Доступно хранилище с файлами, подлежащими обработке, например сетевая папка. Файлы постоянно добавляются в эту папку внешними сервисами.
Необходимо обработать каждый файл и только один раз, результат обработки поместить в другое хранилище тоже в виде файла. Обработанный файл должен быть удалён из исходного хранилища. Обработка всех файлов должна быть выполнена максимально быстро с учётом имеющихся аппаратных возможностей.
  • Предложите список классов и их ответственностей, которые потребуются для решения этой задачи.
  • Предложите реализацию описанного конвейера, репозитории с исходными файлами и результатами обработки, а также сервис обработки одного файла нужно представить интерфейсами, их реализация не требуется.
Ответы присылайте на почту: Ellina.Kozlovskaya@kaspersky.com
Теги:
Хабы:
+21
Комментарии 7
Комментарии Комментарии 7