«Надёжно?» — «Смотря когда вы спрашиваете»
Разговор с Владом Ткачёвым, партнёром по ИТ-аудиту Baker Tilly в регионе Центральная Азия, о том, почему у любого аудита короткий срок годности, чем салями-атака отличается от воровства, и почему самый защищённый бэкап — это тот, до которого не может дотянуться даже всесильный админ.
— Давайте начнём с простого. К вам приходит клиент и спрашивает: «Скажите честно, у нас всё надёжно?» Что вы отвечаете?
Честно? Внутренне вздыхаю. Потому что в этот момент человек ждёт, что я кивну, похлопаю его по плечу и выдам что-то вроде индульгенции — коротко, спокойно и, желательно, бесплатно. А мне вместо этого приходится включать зануду и слегка портить ему настроение.
— Почему сразу зануду? Вопрос ведь нормальный.
Вопрос нормальный, но это ловушка. Не со стороны клиента — он-то спрашивает искренне. Ловушка в самой формулировке. «Всё надёжно?» или «Всё безопасно?» подразумевает, что у надёжности или безопасности есть какое-то устойчивое состояние: да, галочку поставили, живём дальше спокойно. А его не существует.
— Как это не существует? Вот вы провели аудит, система прошла проверку — значит, в эту секунду она надёжна?
В эту секунду — да. Я даже больше скажу: технически она может быть идеальной. Ровно в тот момент, когда мы подписали отчёт, закрыли все рекомендации и пошли пить кофе, она — образец из учебника. Проблема в том, что этот идеальный миг длится примерно до первого админа, который наутро залогинится в систему.
— То есть до обеда?
Иногда буквально до обеда, да. Понимаете, тут важно поменять саму картинку в голове. Информационная система — это не сейф, который поставили в подвал, закрыли и забыли. Это скорее живой организм, который постоянно бурлит. Кто-то увольняется, кому-то выдали права «на пять минут», прилетело обновление, поменялся код, подрядчик что-то подкрутил у себя. Каждое такое движение чуть-чуть меняет ландшафт. Поэтому любой аудит по своей природе — это стоп-кадр. Пока вы открываете PDF с отчётом, реальность в вашей сети уже убежала далеко вперёд.
— Звучит пессимистично. Получается, надёжных и безопасных систем вообще не бывает?
За годы практики я ни разу не встретил систему, про которую можно было бы честно сказать: вот она, абсолютно защищённая и вечно надёжная. Зато я видел сотни красивых, абсолютно правильных на схеме архитектур, которые потом разбивались о самый обычный корпоративный быт. И вот это, если честно, куда интереснее любых учебников. Потому что настоящие поломки почти никогда не выглядят как «взлом» из сериала про хакеров.
— Тогда давайте на историях. Есть у вас любимая — из тех, что показывают, как правильная система ломается в самом неожиданном месте?
Есть, и не одна. Причём я специально расскажу слегка изменённые варианты — по понятным причинам я не могу выносить наружу реальные истории живых клиентов. Но каждая из них собрана из совершенно реальных механизмов, я ничего не преувеличиваю. Начну с той, которую люблю больше всего, потому что в ней нет ни одного злодея.
— Как это — поломка без злоумышленника?
А вот так. Представьте бухгалтера — назовём его образцовым сотрудником, потому что он им и был. Пришёл в компанию восемь лет назад на скромную позицию бухгалтера-расчётчика. За эти годы вырос, прошёл через три отдела, получил несколько повышений — нормальная здоровая карьера, все за него рады. И на каждом шаге этого пути ему честно, по заявке, с подписью руководителя добавляли новый доступ. Перешёл в казначейство — дали права на работу с платежами. Стал старшим — дали право согласования. Подключили к новой системе — выдали ещё одну роль. Каждая отдельная выдача абсолютно обоснована.
— Пока звучит как нормальная работа, а не как проблема.
В том и фокус. Проблема не в том, что ему выдавали. Проблема в том, что забирать старое было никому не нужно. Ни у одного человека в компании не было обязанности при выдаче новых прав спросить: «а что у него уже есть?». Права только накапливались, как вещи на антресолях — заносить заносим, а разбирать руки не доходят. И в какой-то момент оказалось, что один человек может создать платёж, сам же его согласовать и сам же провести. Полный цикл в одних руках.
— И он этим воспользовался?
В этой истории — нет. И это самое важное. Ему просто никогда не давали такой власти единомоментно. Эта «абсолютная власть» натекла сама, в час по чайной ложке за все восемь лет. На бумаге разделение полномочий было идеальным: покажите любой отдельный приказ о доступе — он безупречен. А по факту принцип «тот, кто платит, не должен сам себя проверять» тихо съело время. Вот это я и называю самым честным типом уязвимости: её никто не создавал. Она выросла сама.
Я это для себя формулирую так: права имеют свойство накапливаться, а не растворяться. Ответственность за выдачу есть всегда, а ответственности за изъятие — почти никогда. И если этот перекос не лечить специально, любая, даже идеальная, схема разделения полномочий рано или поздно сползёт в одну пару рук. Не из-за злого умысла. Просто под собственным весом и в отсутствие соответствующих процессов управления.
— Хорошо, это история про то, как всё сломалось само. А есть про обратное — где злой умысел был, но его невозможно было увидеть?
Есть, классика жанра. Её называют салями-атакой — по принципу нарезки: с целого куска незаметно снимаешь по тончайшему ломтику. Представьте разработчика в биллинговой системе. Ему поручают что-то предельно скучное — например, логику округления сумм при расчётах. Задача настолько тривиальная и неинтересная, что её, по-хорошему, никто и никогда не сядет внимательно вычитывать. Ну округление и округление.
— И что можно сделать со скучным округлением?
О, много интересного. Он пишет код так, что при каждой операции дробный остаток — доли копейки, которые возникают при округлении и обычно просто растворяются, — не исчезает, а тихонько капает на один специально заведённый счёт. С каждой отдельной транзакции — исчезающе мало. Настолько мало, что даже если бы кто-то это увидел, он бы отмахнулся. Но система-то проводит миллионы операций в месяц, а то и в неделю. И вот эти микроскопические ручейки сливаются в очень приличную реку.
— Но погодите. Это же прямая недостача. Её обязан поймать любой финансовый контроль чуть ли не в конце закрытия операционного дня или месяца.
А вот и нет — и в этом вся красота приёма, если можно так сказать про воровство. Никакой недостачи в отчётности не возникает. Дебет с кредитом сходятся идеально, до копейки. Потому что деньги не пропадают из системы — они внутри неё перетекают из одного кармана в другой. Регулярный контроль баланса будет кристально чистым: всё сбалансировано, всё сходится. Само воровство происходит гораздо позже, когда на этом счёте накопится приличная сумма и у программиста возникнет соблазн её воспользоваться: либо внутри системы за счёт обмена накопленных средств на предлагаемые организацией товары и услуги, либо за счёт того или иного способа обналичивания или перевода средств за пределы системы. Что же касается аудита кода… ну кто по доброй воле полезет с лупой перечитывать функцию округления, написанную пару лет назад? Она же элементарная, там нечего смотреть.
— То есть поймать это в принципе нельзя?
Можно. Но только одним способом — сменив вопрос. Стандартный контроль всё время спрашивает: «баланс сходится?». А салями-атака специально сконструирована так, чтобы баланс сходился. Поэтому поймать её можно, только задав другой вопрос: не «сходится ли?», а «а почему вот на этом счёте, по которому не было входящих транзакций с момента его создания, за год натекла ощутимая сумма?».
И вот тут проходит очень важная для меня граница. Классический контроль ищет ошибку — то, что не сходится. А хорошо спрятанная атака как раз сходится идеально; её выдаёт не ошибка, а аномалия. Разница фундаментальная. Ошибка — это когда баланс не бьётся. Аномалия — это когда баланс бьётся прекрасно, но само по себе это выглядит странно в свете наличия дополнительной информации и изменения угла зрения. Машина отлично ловит первое и почти слепа ко второму. Поэтому вопрос «всё ли сходится?» мы давно научились задавать автоматике. А вопрос «а нормально ли это вообще выглядит?» пока приходится задавать живому человеку и изобретать новые методы проверки.
— У вас наверняка есть отдельная больная тема. Что раздражает сильнее всего?
Бэкапы. Это прямо мой личный пунктик, могу про них долго. Спрашиваешь: «Резервные копии есть?» — «Обижаете, конечно, всё настроено, всё по расписанию». Спрашиваешь дальше: «А тестируете восстановление?» — «Да, регулярно, поднимаемся без проблем, каждое утро «бизнес» просит развернуть вчерашнюю копию». Всё звучит образцово. А потом приходит шифровальщик — и выясняется самое неприятное.
— Что копий не было?
Хуже. Копии были. И тестировались честно. Засада в другом: эти копии жили в той же самой сети и под теми же самыми учётками, что и боевая система. Просто, условно, «в соседней папке». А шифровальщик, когда попадает внутрь, обычно приходит уже с правами администратора. И он спокойно, методично проходит по всему, до чего дотягивается этот администраторский доступ. Сначала боевая система. Потом, ровно теми же правами, — хранилище резервных копий. И восстанавливать становится нечего: бэкапы зашифрованы вместе с оригиналом, одним движением.
— Логично. Но тогда что вообще считать нормальным бэкапом?
Резервная копия, до которой дотягивается самый привилегированный человек в компании, — это, строго говоря, не резервная копия. Это просто вторая мишень, которую любезно положили рядом с первой. Настоящий бэкап — это холодная, оффлайновая копия. Физически отрезанная от сети. Такая, до которой не может добраться вообще никто — включая всемогущего айтишника с root-доступом, включая, если угодно, вас самих в роли администратора.
— Но это же дико неудобно.
Абсолютно. Это неудобно, это выглядит архаично, это раздражает — каждый раз кто-нибудь предлагает «ну давайте уже подключим её к сети, чтобы автоматизировать». И вот именно эту неудобную, «глупую», оторванную от всего копию нельзя трогать ни в коем случае. Потому что смысл резервной копии не в том, чтобы она была удобной. Смысл в том, чтобы до неё не дотянулось то же самое, что уничтожило основную систему. Я это формулирую так: бэкап, доступный из той же сети под теми же правами, — это не резервная копия, это второй экземпляр той же мишени. Спасает только та копия, которую не достаёт никто.
— Если собрать эти три истории вместе — что их роднит?
Во всех трёх система была технически исправна. Права выдавались по заявкам. Округление работало корректно. Бэкапы делались по расписанию. Формально не подкопаешься ни к одному пункту. И тем не менее каждая из этих систем была уязвима — просто уязвимость пряталась не в настройках, а в процессах вокруг них. В том, кто и как выдаёт права. В том, какой вопрос задают отчётности. В том, где физически лежит копия.
Отсюда моя главная мысль, к которой я в итоге всегда прихожу: надёжность — это не свойство конфигурации. Это свойство процессов. Системы почти никогда не ломаются сами по себе, на ровном месте. Их ломают две вещи — изменения, прошедшие без контроля, и решения, принятые ради сиюминутного удобства, а не ради безопасности.
— Тогда получается, что классический технический аудит — «проверить железо и софт» — не так уж и полезен?
Он полезен, но сам по себе неполон. Аудит, который смотрит только на железо и софт в отрыве от людей и процессов, — это технически безупречная, но довольно бесполезная бумага. Она честно фиксирует, что у вас есть прямо сейчас, в эту секунду. И полностью молчит о том, что будет завтра, когда наступит понедельник и все снова начнут что-то менять, выдавать, подкручивать и «временно» открывать.
— И поэтому сегодня, когда вас спрашивают про надёжность…
…я давно уже смотрю не на настройки фаервола. Я смотрю на то, как в компании устроена работа с изменениями. Кто принимает решения и как. Что происходит, когда «очень надо и прямо сейчас». Забирает ли кто-нибудь права или их только выдают. Куда физически едет бэкап. Если эти процессы кривые — не спасёт никакой софт, каким бы дорогим он ни был. А если процессы здоровые — там, как правило, и с софтом всё в порядке. Потому что здоровые процессы — это просто отражение того, что в компании привыкли думать на один шаг вперёд.
Об эксперте
Влад Ткачёв — партнёр по ИТ-аудиту Baker Tilly в регионе Центральная Азия. Соучредитель Центра информационной безопасности в Кыргызской Республике, независимый эксперт и консультант в сфере ИКТ и информационной безопасности для государственных и международных организаций. Член экспертного совета при государственном органе по защите персональных данных и участник рабочей группы по разработке Цифрового кодекса КР.
CISA, Lead Auditor ISO 27001, Сертифицированный негосударственный судебный эксперт по специальности «Исследование информационных компьютерных средств» (код 21.1, сертификат соответствия СТО-НСЭ-2016 №013351); член Палаты судебных экспертов им. Ю. Г. Корухова («СУДЭКС», Москва), реестровый №3290.
В сфере ИКТ и информационной безопасности — с 2002 года. За 24 года практики участвовал в десятках местных и международных проектов: проведение ИТ-аудита, оказание услуг ИТ-консалтинга, оценка и проектирование сложных информационных систем, расследование компьютерных инцидентов, выстраивание защиты, раннее обнаружение и предотвращение угроз.