В декабре россияне масштабно атаковали базовые реестры Минюста, в частности самые важные цели: Государственный реестр актов гражданского состояния, Единый государственный реестр юридических лиц и Государственный реестр вещных прав. Все они имеют статус так называемых базовых реестров в Украине. Поэтому мгновенно остановились все действия в сфере недвижимости и бизнеса, государственные программы «єОселя» и «єВідновлення», торги на бирже, назначение людей на государственную службу, государственные закупки, оформление отсрочек, рассмотрение части судебных дел, работа нотариусов и еще куча е-услуг в «Дії» и других государственных приложениях.
Все эти на первый взгляд не связанные между собой процедуры объединены потребностью проверять базовую информацию о гражданах, бизнесе и недвижимом имуществе во время разных бюрократических операций. Если вы хотите осуществить какое-либо действие с компанией или ФЛП (например, выдать разрешение), то вам нужно проверить, существует ли эта компания, не закрыта ли она, имеет ли право кто-то от ее имени подписывать документы и т.п. Для проведения этих проверок реестры и системы «бегают» в «ЄДР». Если вы предоставляете административные услуги гражданам, это часто требует проверки наличия брака, родственных связей. Например, услуга «єМалятко» или оформление отсрочки для многодетных родителей нуждаются в данных из ГРАГС. Если же нужно сделать что-то с домом, например, подать заявление на «єВідновлення» после прилета ракеты, — это в ГРВП (Государственный реестр вещных прав).
Время атаки враг выбрал неслучайно. В течение определенного периода хакеры уже имели доступ к реестрам, поэтому явно выжидали удачный момент для удаления данных. В конце года в государственных органах происходит видимо-невидимо важных процессов, для которых прежде всего нужен «Єдиний державний реєстр» юридических лиц. Из самого главного — государственные закупки. Ведь если госорган не успевает до конца календарного года израсходовать средства, предусмотренные для него бюджетом, он их теряет. Поэтому традиционно конец декабря — время, когда разные государственные институты проводят много важных закупок, иногда на двузначные проценты своих годовых бюджетов. Соответственно, после атаки закупки остановились, потому что компании не могут участвовать в тендерах/других процедурах — все они требуют актуальной выписки из «ЄДР». Опять же, в условиях войны речь идет о важных тендерах Агентства оборонных закупок и Государственного оператора тыла. Хотя и гражданские сферы сильно пострадают (например медзакупки).
То есть о последствиях атаки можно писать долго, но это без преувеличения паралич цифровой системы страны, бюрократический коллапс государственных функций. И хотя виноваты россияне, но ответственность уже несем мы, восстанавливая реестры с «холодных» копий. Так, 30 декабря работу нескольких систем уже возобновили. Поэтому пришло время на холодную голову немного лучше оценить сложившуюся ситуацию. Она должна стать основой для рефлексии и поиска первопричин явно недостаточной защищенности государственных систем. Иначе подобное может произойти с другими ключевыми данными пенсионных, медицинских и социальных систем в Украине.
Кто виноват? Кто ответственный?
В сложной структуре государственных органов трудно сразу понять, кто же ответственный за безопасность реестра. Поэтому рассмотрим всех, на кого обычно «вешают собак».
Ключевую ответственность, согласно законодательству (то есть юридически), несет владелец/распорядитель реестра, который является главным заказчиком его создания, поддержки и наполнения. То есть Минюст — это первый элемент цепочки.
Но обычно у министерства нет в штате нужного количества разных специалистов, поэтому в больших ведомствах бывают отдельные подчиненные госпредприятия, являющиеся администраторами систем. В контексте Минюста это специализированное Государственное предприятие «Национальные информационные системы» (ГП «НАИС») — второе в цепочке. Именно оно технически отвечает за кибербезопасность этих реестров и фактически должно «отражать» такие атаки. Но поскольку Минюст — владелец, то он все равно ответственен за контроль над работой ГП «НАИС». Министерство выдает средства, определяет руководство и должно следить за качеством работы госпредприятия.
Кроме того, много обвинений можно услышать в адрес Госспецсвязи и Минцифры. Разберемся в их роли.
Государственная служба специальной связи и защиты информации (ГСССЗИ) — третья в цепочке как основной субъект гарантирования кибербезопасности в Украине. Именно она проводит экспертизу КСЗИ — комплексных систем защиты информации. Проще говоря — должна следить, что все обеспечивают защиту своих решений во всем правительстве. ГСССЗИ несет ответственность, но другого сорта, более стратегическую и верхнеуровневую. Она о том, что практики и процессы киберзащиты в стране должным образом не работают, что аттестаты соответствия КСЗИ — это формализм, не означающий, что ваши системы действительно защищены. Поэтому Госспецсвязь, скорее, ответственна за состояние отрасли в целом, симптомом чего являются отдельные взломы.
Минцифры здесь оказывает меньше всего прямого влияния. Оно может формировать политический запрос на кибербезопасность, помогать ГСССЗИ с реформами, но это не является его прямой ответственностью. Поэтому если упрощенно и по сути:
- технически ответственность несет ГП «НАИС»;
- в плане управления ответственен Минюст, потому что должен смотреть, делает ли НАИС все правильно, контролировать, чтобы решения были качественными, современными, защищенными;
- ГСССЗИ несет минимальную ответственность, потому что фактически может обвинить Минюст в неэффективности, но не контролирует систему практически;
- обвинять Минцифры нет особого смысла.
Если подытожить, то кибербезопасность — это слишком комплексная задача, чтобы определить одного «козла отпущения». Да и, будем откровенны, иногда происходят такие кибератаки, которые технически невозможно отразить. Ведь в войне всегда есть «гонки копья и щита». Более того, хотя Минюст и является ключевым ответственным, там сейчас новая команда, а проблема с ГП «НАИС» досталась ей в наследство, переходя из рук в руки каждому следующему руководителю министерства. Намного конструктивнее разговоров, кого бы уволить, поговорить о том, что нужно исправить, на каких этапах и как подготовиться к следующим атакам россиян.
Шаг 1. Конкурентные закупки IT-услуг
В украинском GovTech есть старая традиция вендорлок, или обычным языком — монополия поставщика. Многие украинские ведомства работают с определенными подрядчиками, которые злоупотребляют эксклюзивным положением. Они намеренно монополизируют доступ к системам. Например разрабатывают сервисы на уникальных и редчайших технологиях. Иногда это малораспространенные языки программирования, как Elixir, которыми владеют максимум несколько сотен специалистов. Иногда используют другие трюки, например, делают свою «кастомизацию» языка программирования, которым владеет только эта компания. Часто еще банальнее — избегают написания документации, передачи прав на продукт или просто саботируют передачу паролей/доступов другим подрядчикам. Нередко в этом замешаны коррупционные договоренности с самими заказчиками.
Эта монополия разрушает системы изнутри. Потому что, с одной стороны, у разработчиков нет мотивации работать над качественными сервисами и их защитой — как 15 лет назад создавали системы, так и сейчас их будем создавать, зачем овладевать новыми технологиями и внедрять инновационные подходы? У них «вечный и дармовой контракт», который никто никогда не заменит. Это уже не говоря о возможности ставить нерыночные и завышенные цены. Собственно, Минюст находится именно в такой зависимости.
А с другой стороны, сам заказчик даже при наличии политической воли не имеет рычагов влияния на подрядчика, когда хочет продукт лучшего качества. Поскольку, если только этот подрядчик, условно говоря, уже 10 лет делает определенный реестр и имеет исключительный доступ/опыт в этой специфической сфере/понимании инфраструктуры, заказчик не может пригрозить ему завершением контракта, если тот не соблюдает требования качества.
Более того, если зависимость насколько сильная, что именно вендор и администрирует системы, то идти против него становится просто опасно, потому что без его «надзора» система может перестать функционировать.
Поэтому допускать такую ситуацию крайне опасно. А если такое положение дел досталось в наследство, нужно активно бороться с монополией. Здесь нет задачи только сменить компанию любой ценой, важно дать возможность работать над системой другим или сменить компанию, если она не выполняет требования по качеству.
Шаг 2. Нормальные сроки разработки
Украинские реалии запуска электронных систем таковы, что продукты заказывают «на вчера». У нас, к сожалению, воплощают мало долгих системных реформ. Вместо этого короткое окно возможностей, телефонный запрос из вышестоящей инстанции или офиса президента, внезапная смена кадров и приход реформаторов на руководящие должности служат причиной запроса на быстрые релизы. В таких условиях разработчики, даже если они профессионалы, в лучшем случае урезают этап тестирования. А в худшем — и функционал системы. Соответственно, в релиз часто идут сырые продукты, в частности поверхностно оттестированные с точки зрения безопасности.
Иногда разработчики даже знают, что нужно доработать и где было «схалтурено». Но из-за все новых и новых проектов с «горящими сроками» эти доработки откладывают надолго в так называемый технический долг. Его часто должным образом не доделывают. Со времен работы в Министерстве здравоохранения помню кейс, когда технический долг «ЕСОЗ» был соразмерен всем будущим работам по развитию системы, запланированным на ближайший год. Тогда ресурс на «закрытие долга» было крайне сложно приоритезировать, потому что новые задачи сыпались отовсюду. Обычно на такой объем технических, архитектурных проблем и проблем в сфере безопасности и т.п. никто годами не обращает внимания. Потому что это большой объем работы, который в то же время не приносит публичных результатов — министр не отчитается красиво в медиа о новых достижениях или запущенных е-сервисах.
В комбинации с недобропорядочным вендором, который не мотивирован к качественной работе и его невозможно к ней вынудить (см. пункт первый), этот технический долг обречен бесконечно накапливаться.
Шаг 3. Надлежащая проверка государственных IT-cистем
Все пораженные реестры, очевидно, прошли экспертизу комплексной системы защиты информации и имеют аттестаты соответствия. Но между аттестатом и реальной безопасностью — если не пропасть, то точно очень большое расстояние. Основные документы, такие как Закон Украины «О защите информации в информационно-коммуникационных системах», были приняты в 1990-х и 2000-х годах и лишь частично обновлялись. Чаще всего все нормы были выдуманы в то время, когда еще не было ни облачных технологий, ни распределенных баз данных. Эта законодательная база ориентирована на традиционные физические и программные методы защиты. Которые все еще необходимы, но их недостаточно.
Проще говоря, правила кибербезопасности отстают от современных тенденций и чаще всего сфокусированы на том, чтобы «выдать бумажку». Они нуждаются в заметном обновлении как стандартов безопасности, так и подходов к ее оценке.
И даже если навести порядок в КСЗИ, важно, чтобы эта процедура, как и другие функции Государственной службы специальной связи и защиты информации, не была формальностью. Во время моей работы на таможне мы наблюдали ситуацию, когда ІТ-системы Гостаможслужбы не то что не имели аттестата соответствия КСЗИ — часть из них даже не была на балансе. То есть формально ее просто не существовало, таможня работала в чем-то, что ей даже не принадлежало. А какие-либо обращения или требования ГСССЗИ или других органов просто игнорировались. Таможенники даже не допускали никого к системе, чтобы ее проверить. Так о какой кибербезопасности на таможне могла идти речь, если даже специальные уполномоченные органы не имели возможности взаимодействовать с системой?
А пока до реформы ГСССЗИ далеко, конечную ответственность за реестры несут распорядители данных. Данные будут восстанавливать с магнитных лент (в огромных узлах и на бобинах, как в фильмах о старых компьютерах). Это самый резервный формат хранения, последняя инстанция, к которой можно прибегнуть, если все облачные резервные копии уничтожены. Пока неясно, когда делался этот физический бэкап и насколько устаревшая информация на этих носителях.
Шаг 4. Политики безопасности относительно кадров и их инструментов
Защищать надо не только продукт, но и рабочие места, внутренний периметр. Многие ведомства не уделяют достаточно внимания защите компьютеров, почты, программ и других инструментов, с которыми работают люди. Условно говоря, у вас может быть чрезвычайно защищенная система, но если хакер получил доступ к компьютеру администратора, все это напрасно. Часто даже с компьютера простого работника, имеющего очень скромные права доступа, можно получить много всего. Например, «слить» все данные, внести недостоверные. Это дополнительное окно проникновения в систему.
И кибербезопасность имеет человеческое измерение. В случае с Минюстом уже звучали заявления о том, что атака на его реестры произошла с учетной записи высшего уровня. Всегда остается риск, что люди могут быть завербованы подкупом или угрозами. Также человек может быть не тот, за кого себя выдает, и иметь нежелательные связи. Для этого есть полиграф и другие проверки. Они должны быть внедрены не только в оборонной сфере.
Здесь сознаюсь, что мы тоже не всегда внимательно следим за этими пунктами. Помню, когда я был просто сотрудником на донорском контракте, я и моя команда могли иметь доступ ко многим системам. Часто мы не соблюдали контроль и не проверяли людей, которым предоставляли доступ, не контролировали их рабочие устройства (иногда они работали с личных ПК, у команд реформ часто нет ресурса на отдельные рабочие). Более того, над выданными доступами иногда бывает не лучший контроль. Например, у меня до сих пор есть доступ к определенным системам, над которыми я работал как проектный менеджер восемь лет назад. К системам с десятками миллионов записей чувствительных данных. Много раз напоминал админам забрать этот доступ у меня — но, очевидно, руки у них не доходили.
Домашнее задание
Во-первых, вендорлок — это зло. Только здоровая конкуренция между потенциальными вендорами государственных органов породит здоровое предложение и функциональные продукты. Заказчикам давно пора избавиться от зависимости от компаний, разобраться в рынке GovTech и разнообразить списки подрядчиков через конкурентные тендеры. После привлечения лучших вендоров для создания продукта необходимо лучшее планирование: запланированное время на полноценное тестирование и настройки безопасности.
Во-вторых, реформа Госспецсвязи перезрела. Сейчас прогресс в этой теме есть, но он слишком медленный.
В-третьих, даже лучшая система не застрахована от человеческого фактора. Проверять людей и иметь четкие политики относительно средств их работы (техники, программ и т.п.) — это не просто совет из личной информационной безопасности, это о национальной безопасности в условиях войны.
Если резюмировать, то последствия декабрьской атаки мы будем разгребать еще не один месяц, несмотря на то, что первые реестры уже восстановлены. Но важно сделать из нее выводы и подготовиться к следующей. Несколько кадровых изменений, уже проведенных в Минюсте, — это неплохо для начала. Но нельзя на этом останавливаться. Потому что горячечное «снесение голов» — это не полноценное изменение процедур безопасности вокруг государственных систем.