На чем написан касперский
«Лаборатория Касперского» — один из мировых лидеров в сфере кибербезопасности. Специализируется на разработке защитных систем от киберугроз. Управление осуществляется из центрального офиса, расположенного в Москве, и из 5 штаб-квартир региональных дивизионов. Партнерская сеть объединяет более семи сотен партнеров 1-го уровня, действующих более чем в 100 странах.
Расширение сферы деятельности
В 2000 году основной продукт бренда получил новое официальное название Антивирус Касперского®. Потребителям предлагали максимально дифференцированную линейку: продукты для домашнего использования, представителей среднего и малого бизнеса, корпоративных клиентов.
В 2001 году оборот Kaspersky lab достиг около 7 миллионов долларов, в 2006 году — превысил 67 миллионов. За это время она превратилась в одного из лидеров антивирусных корпораций и у нее появилась сеть, охватывающая большинство регионов планеты. В 2002 году сфера деятельности была расширена. Цель ‒ защита клиентов от любых угроз информационной безопасности. Пользователям представители персональную систему защиты от спама и межсетевого экрана.
За 2001—2002 годы была разработана DLP-система для защиты корпоративных пользователей от внутренних угроз, а в конце 2003 года, с целью развития и дистрибуции нового продукта, появилась дочерняя фирма InfoWatch.
Контракт с ФСО и разрыв с Business Software Alliance
В 2011 году 20 % акций бренда купила фирма General Atlantic, заплатив 200 миллионов долларов. Однако сделать «Лабораторию» публичной так и не удалось. Спустя несколько месяцев акции были выкуплены Евгением Касперским. Тогда же был заключен важный контракт с ФСО на поставку своих продуктов.
1 января 2012 года компания официально покинула Business Software Alliance. Причина разногласий была в поддержке Альянсом закона о борьбе с пиратством. Kaspersky lab высказался категорически против. Представители бренда заявили, что меры, прописанные в новом законе, могут быть использованы в ущерб потребностям потребителей.
Создание AVP
Весной 1991 года старший лейтенант Е. Касперский был уволен из армии «по служебному несоответствию». Добиться увольнения было сложно, и процедура заняла почти год. Друзья и знакомые отговаривали его от такого решительного шага. Однако супруга Наталья поддержала Евгения.
В 1991 году Касперский устроился на работу в компанию «Ками», президентом которой был Алексей Ремизов. Он выбрал этот вариант из нескольких предложений, так как этому времени уже был «нарасхват». В 1994 году разработанное Евгением антивирусное ПО AVP, по результатам тестирования университет Гамбурга, заняла первое место. Большинство пользователей были нелегальными, поэтому «Ками» оказалось в сложном финансовом положении. Ситуация улучшилась, когда появились первые дистрибьюторы из Италии и Швейцарии.
В 1994 году к работе подключилась Наталья Касперская, которая на тот момент была женой Евгения. Она поступила в антивирусный отдел «Ками» на должность менеджера и занялась налаживанием сбыта продукции — ПО AntiViral Toolkit Pro. Продукт на тот момент стоил 55 долларов США, что по тем временам было недешево.
Важной вехой в истории budu]ego Brenda Kaspersky стало подписание договоров с финской фирмой F-Secure и российской «1С».
Поглощение RAV и экспансия на Восток и в Африку
В 2003 году динамичное развитие продолжилось. Частью коллектива стала талантливая румынская команда создателей антивируса RAV. На рынке появились новые версии уже популярных и принципиально новые продукты. Одной из новинок стал Kaspersky Security, предназначенный для PDA (Personal Digital Assistant). Такое ПО защищало данные не только от вирусов, но и от несанкционированного доступа.
Во второй половине 2000-х годов началась активная экспансия бренда по многим региональным направлениям. Были открыты представительства в нескольких странах, включая КНР и Японию.
Летом 2007 года Е. Касперский отстранил бывшую к тому моменту супругу — Наталью от управления фирмой и сам занял должность генерального директора. Тогда же Наталья возглавила InfoWatch. К ней перешел и контрольный пакет акций этой фирмы, как часть имущества, доставшегося ей после развода.
В 2008 году появились новые офисы на Ближнем Востоке, а в 2009 году — в Южной Африке. В 2010 году были основаны офисы в Индии. К этому времени ежегодные объемы розничных продаж антивирусного ПО «Лаборатории Касперского» повысились почти 4,5 миллиона копий.
Как все начиналось
Началом истории бренда можно считать 1989 год, когда выпускник Высшей школы КГБ Евгений Валентинович Касперский создал свою первую антивирусную программу. Ее код был написан, когда он служил в одном из засекреченных институтов Генштаба ВС СССР, и нужно было «почистить» рабочий ПК.
Как и другие жители Советского Союза в годы Перестройки, Евгений искал дополнительный источник дохода. Однако быстро понял, что не имеет способностей для занятий коммерцией. Со временем количество программ, для противодействия вирусам, написанных Касперским, стало расти. Но сам он рассматривал это занятие только как хобби. Идея монетизировать свои способности в этой области пришла, когда к нему начали обращаться за помощью.
Немногочисленные заказы не приносили существенного дохода. Ситуация изменилась, когда с Евгением заключила контракт компания, поставившая в страну большую партию персональных компьютеров. Требовалось установить на них антивирусное ПО. На вырученные деньги была издана первая книга Евгения «Компьютерные вирусы в MS-DOS»
Разбирательство с Microsoft и шпионский скандал.
В начале 2017 года российские правоохранители арестовали бывший офицера МВД, курировавшего отдел расследования «Лаборатории Касперского» Р. Стоянов. Мужчине предъявили обвинение в государственной измене, а данные следствия засекретили.
Но 2017 год для бренда запомнился не этим. Он осуществил свое намерение, анонсированное еще в 2016 году, и подал иск к Microsoft в Еврокомиссию. В нем он обвинила американскую корпорацию в навязывании пользователям своего антивирусного ПО Windows Defender. По мнению российской, компании, тем самым Microsoft ограничивала права выбора своих клиентов, что приводило к финансовым потерям, как самих пользователей, так и других разработчиков защитных решений. Их оппонент сначала не соглашался с обвинениями. Однако позже стало известно, что иски отозваны, так как американский ИТ-гигант согласился выполнить требования Kaspersky lab.
Что дальше
Весной 2019 года компания заговорила о намерении стать совладельцем отечественного разработчика ПО «Новые облачные технологии». Однако в целом год был не слишком удачным. Впервые за достаточно длительный период выручка не возросла, а упала до 684,6 миллиона долларов.
Корпорация совершила решительный шаг. В результате ребрендинга она изменила название на Kaspersky, избавившись от слова «lab».
В ноябре 2020 года компания перенесла данные значительной части зарубежных клиентов в Швейцарию. Она завершила также анонсированную двумя годами ранее миграцию инфраструктуры для обработки и хранения данных. Все это было сделано с целью продемонстрировать честность и прозрачность бренда, а также для предоставления независимого аудита кода.
На данный момент «Лаборатории Касперского» продолжает защищать российских интернет-пользователей, использующих ее антивирусные продукты. Только за первые 6 месяцев 2021 года с их помощью было предотвращено более 36 миллионов попыток перехода на фишинговые сайты, из которых почти 1/3 были скамерскими. Благодаря ПО от бренда Kaspersky не были осуществлены 300 тысяч попыток перехода на сайты-«фальшивки», мимикрирующие под интернет-ресурсы известных финансовых организаций. Для этого компания применяет множество технологий, включая нейросети. С их помощью детектируются новые, малоизвестные виды фишинга.
Рекомендуем почитать:
Эксперты «Лаборатории Касперского» обратились к сообществу с просьбой помочь разобраться, как работает программный код, который составляет значительную часть в основном компоненте Duqu, то есть в payload DLL, и вообще — на каком языке программирования написан этот код?
На диаграмме секция с таинственным программным кодом обозначена красным цветом, специалисты «Лаборатории Касперского» назвали её «Фреймворком Duqu» (именно так, с большой буквы).
Вот что пишет Игорь Суменков, эксперт «Лаборатории Касперского»:
На первый взгляд, Payload DLL выглядит как обычная загружаемая библиотека формата Windows PE, скомпилированная Microsoft Visual Studio 2008 (версия компоновщика 9.0). Код, расположенный в точке входа, абсолютно стандартный. Единственная экспортируемая функция под номером 1 тоже написана на MSVC++. Эта функция вызывается из PNF DLL и реализует весь функционал данной библиотеки — соединение и общение с C&C серверами, получение и выполнение дополнительных модулей троянца. Интересные детали обнаруживаются при более глубоком анализе кода, который вызывается этой функцией в процессе работы.
Содержимое секции кода Payload DLL типично для исполняемого файла, скомпонованного из нескольких исходных модулей. Секцию можно условно разделить на несколько разделов, каждый из которых соответствует одному или нескольким файлам исходного кода. Большая часть разделов присутствует в любой программе, написанной на C++, — это, например, функции стандартной библиотеки шаблонов STL, функции стандартной библиотеки языка и собственно код программы. Однако самый большой раздел, реализующий всю логику общения с C&C серверами, отличается от них во всём.
Этот раздел не типичен для C++ программ, потому что его исходный код – не C++. Код внутри раздела не обращается к другим функциям программы, написанным на C++, и не использует стандартную библиотеку языка, хотя используемые парадигмы явно указывают, что исходный текст был написан на объектно-ориентированном языке программирования. Мы назвали это Фреймворком Duqu.
Далее эксперты «лаборатории Касперского» пытаются разобраться, каким образом работает объектно-ориентированный язык во фреймворке Duqu. Они отмечают, что весь функционал в коде реализуют объекты, все они являются экземплярами какого-либо класса, всего в коде обнаружено 60 различных классов. Таблица функций объекта находится непосредственно в его памяти и может быть изменена в процессе выполнения. Во фреймворке активно используется парадигма так называемого событийно-ориентированного программирования.
Специалисты «Лаборатории Касперского» с ноября 2011 года потратили много времени на анализ кода и делают вывод, что фреймворк Duqu написан не на Visual C++, а загадочный язык программирования — определённо не C++, не Objective C, не Java, не Python, не Ada, не Lua и ещё не 30 других языков программирования, которые они проверили. «Лаборатория Касперского» обратились за помощью к самым опытным профессионалам по реверс-инжинирингу, которых смогла найти, но те тоже ничем не смогли помочь.
C помощью эксперта «Лаборатории Касперского» разбираемся, какой набор инструментов должен иметь в своем арсенале современный специалист по ИБ. От каких угроз и с помощью каких технологий надо защищаться. Говорим о тенденциях в сфере ИБ, о механизмах работы некоторых продуктов «Лаборатории Касперского» и немного заглядываем в будущее.
Сегодня массовые атаки и различные «выбросы» в сеть уже воспринимаются как нечто обыденное, а купить вредонос в DarkNet или заказать DDOS можно недорого и без особых проблем. Как итог — появляются примеры, как школьники, заплатив небольшие деньги, «дидосят» электронный дневник.
С другой стороны, киберпреступники стали более избирательными и всесторонне исследуют цель, прежде чем целенаправленно атаковать ее.
У «Лаборатории Касперского» есть статистика: с 1986 по 2016 годы было разработано около 1 млн зловредов. За последние два года ситуация изменилась: еженедельно в базах фиксируется 2 млн новых зловредов массового поражения, которые выбрасываются в сеть.
Какие же инструменты приходят на помощь специалистам по безопасности, когда вариант «лучшая защита — это нападение» не уместен?
Капитанская вещь, но: для защиты рабочей станции как минимум необходимо использовать всем давно знакомый антивирус. Впрочем, благодаря политике Microsoft, он сейчас есть на каждой машине с Windows. В пик роста кибератак и удивительной находчивости хакеров многие считают, что антивирус работает лишь как плацебо: поставил его на машину и спи себе спокойно.
Ну а если какая-то зловреда таки просочится через такую «лжезащиту», восстановим машину из бэкапа у хороших админов он же всегда есть , поругаем создателя антивируса, еще пару дней плохого настроения от воспоминаний, и все проблемы уйдут. Правда, бывают случаи, когда зараженная машина наносит заметный ущерб коммерческой деятельности.
На сегодняшний момент классический антивирус, который сигнатурно проверяет файлы, действительно не эффективен. Злоумышленники стали активнее и умнее. Поэтому для защиты рабочих станций нужно использовать продукт, совмещающий в себе как классический антивирус, так и разнообразные варианты поиска вредоноса, например, по поведению.
Не стоит забывать о таких важных вещах, как мониторинг уязвимости в программах на всех машинах предприятия, антивирусные проверки файлов в оперативной памяти и на флешках, проверку почтового и веб-трафика.
Кроме того, очень полезна централизованная консоль управления, где можно мониторить все машины компании, видеть угрозы, вести статистику и выполнять задачи удаленного администрирования. Она просто необходима для распределенных организаций. У многих компаний есть соответствующие решения. В той же «Лаборатории Касперского» оно называется Kaspersky Endpoint Security для бизнеса.
Многие организации переводят свои мощности на виртуальные машины. В данном случае виртуальную среду тоже необходимо как-то защищать. Можно, конечно, поставить защиту на каждую такую машину, но так как обычно виртуалкам выделяется мало ресурсов, то хорошо бы строить защиту виртуальный среды с отдельной виртуальной машины. Выделенная машина обрабатывает все данные, а на рабочие виртуалки устанавливаться только агент, который не дает большой нагрузки.
Можно также использовать агентское решение, доступное только для VMware. В этом случае агент не устанавливается на виртуальную машину, а осуществляет защиту и проверяет машины на наличие угроз через гипервизор. Именно такая схема реализована в том же Kaspersky Security для виртуальных и облачных сред.
Все большую популярность набирают гибридные инфраструктуры: когда часть серверов в облаке и часть на земле. Для построения такой инфраструктуры можно использовать Microsoft Azure. Что касается защиты, то у «Лаборатории Касперского» есть подходящее решение — Kaspersky Cloud Security.
Шифрование — важная часть информационной безопасности. Сотрудники компании для мобильности часто используют ноутбуки, которые можно потерять и легко украсть. Поэтому для защиты конфиденциальных данных необходимо шифровать не только конечные устройства, но и дисковое пространство, а также почтовый и веб-трафик, каналы связи. Для шифрования трафика можно использовать продукты от Cisco, OpenVPN, VipNet, Континента. У «Лаборатории Касперского» на этот случай есть Kaspersky Secure Mail Gateway, который помимо защитных функций (антивирус/антиспам/антифишинг), позволяет шифровать почтовый трафик и принимать только шифрованный трафик с валидным сертификатом.
Если злоумышленник пробрался во внутрь сети и на 443-й повесил ssh, а потом пошел на другую машину и с нее хочет подключится и выполнить вредоносные действия, то у него ничего не выйдет. В случае использования классического firewall — по 443 порту можно делать все, что хотите. В качестве open source варианта для создания firewall можно рассмотреть pfSense, который, кроме основных функций, предоставляет возможности по маршрутизации и балансировке трафика.
DDOS — штука неприятная. К тому же если конкуренты решили вывести ваш сайт из строя в самое неподходящее время, то атака может вылиться в большие потери.
Есть второй вариант работы, когда «Лаборатория Касперского», через средства мониторинга, контролирует назревающую DDoS-атаку и сообщает о ней заказчику, а заказчик принимает решение прогонять свой трафик в данный момент через центры очистки или нет.
В принципе, все названные выше решения позволяют защититься от 99% вредоносов, но всегда остается 1%, не значащийся в сигнатурных базах и созданный для одной конкретной атаки, которая может нанести большой ущерб. В той же «Лаборатории Касперского» разработали Kaspersky Anti Target Attack Platform. Это решение принимает на себя SPAN-трафик, который подается сетевому оборудованию, почтовый трафик, трафик с рабочих мест. Внутри платформы установлен антивирусный движок, который проверяет весь этот трафик и выдает антивирусные детекты. SPAN-трафик, в свою очередь, компонентом IDS проверяется на наличие аномалий в сетевом трафике.
Еще один компонент платформы — песочница — изолированная среда, в которой запускаются файлы и анализируется их поведение.
Может показаться, что в крупную ИБ-компанию очень сложно попасть: нужно пройти семь кругов ада, найти подвох в любой задаче, знать биографию всех руководителей и всю подноготную самой компании. Так ли это? Глава управления базовых технологий «Лаборатории Касперского» Игорь Маслов сам когда-то проходил этот путь: семь лет назад он пришел на очное собеседование, а сейчас руководит одним из ключевых отделов и решает нетривиальные задачи. Мы поговорили с ним — о том, кого и за что берут в «Лабораторию Касперского», спокойно ли живется разработчикам, какие скиллы способствуют карьерному росту и как в ближайшее время изменится процесс разработки. Для стойких и уверенных в себе бонус: тестовое задание — пропуск на финальное собеседование в компанию.
— Я руковожу управлением базовых технологий численностью в 150 человек. Это отдел, который занимается созданием «кирпичиков» для антивирусов. «Кирпичики» используются во всех наших продуктах: десктопных, корпоративных, серверных. Это в основном С++ код, осуществляющий бизнес-логику. Он отвечает за обновление баз, отправку различной статистики в наши облака, перехват системных событий, агрегацию событий, которые перехватили, от наших драйверов и передачу их в движки, за реакцию на эти события: блокировку, подмену трафика (когда хотим показать страничку и сказать, что данные конкретной странички — фишинг).
— В «Лабораторию Касперского» я пришел около 7 лет назад. Меня позвали просто как С++ разработчика, без особой конкретики. Вообще по вакансиям, особенно для программистов, зачастую сложно понять, чем в итоге придется заниматься. В неприметном месте можно найти интересный стартап или, наоборот, кажется, что компания хорошая — а по факту приходится писать банальные скрипты.
Так вот, я пришел, прошел несколько технических собеседований. Вообще первое должно было быть в Anti-Malware Research — это исследовательское подразделение, которое занимается антивирусной защитой, разрабатывает технологии. Но я не фанат research-подразделений — мне нравится создавать продукты, быть ближе к разработке, чтобы пользователи могли быстрее увидеть фичи. Да и сами фичи более явные. В research-подразделении улучшение какого-нибудь детекта не так заметно.
Я спросил прямо у входа: «Это у вас какое подразделение?». Мне говорят: «Anti-Malware Research». Я говорю: «Ресерчем надо заниматься?» «— Ну да». «— Ой, а я не хочу в ресерч-подразделение». Это было первое собеседование.
— Я помню основной смысл. Проверяли знание языка, в основном С++, понимание exception safety, конструкций языка, классов, виртуализации. Еще мне предложили разработать не очень сложный алгоритм. И, соответственно, WinAPI. Вообще на собеседованиях в «Лаборатории Касперского» спрашивают по той платформе, с которой будет работать человек. Устройство памяти, процессов, потоков.
— Я присутствую на технических собеседованиях в своей продуктовой команде. До недавнего времени я программировал, скиллы вроде не потерял, для собеседования их хватает.
— Сейчас мы делаем больший упор на алгоритмы и архитектуру ОС и меньший — на язык программирования. Я люблю спрашивать про память: что такое виртуальная память, как она устроена, как в современных процессорах мапятся физический и виртуальный адреса. И про всякие подводные камни, особенности работы.
— Базовый принцип: собеседование проводят потенциальные коллеги кандидата. Обычно это старшие разработчики, тимлиды. Мы считаем, что в процессе разговора можно не только выявить технические скиллы, но и понять, приятно ли общаться с человеком, будет ли комфортно работать с ним. Ведь разработка — это не просто хардкорный кодинг, но и общение. Поэтому и люди нам нужны компанейские.
С интересным кандидатом я могу дополнительно пообщаться лично — по телефону или даже в телеграме. Мы вообще всегда оставляем кандидату контакты, чтобы можно было уточнить непонятные вопросы после собеседования. Вот, например, недавно я взял человека, с которым общался по телефону два или три раза по полчаса. Он остался доволен и пришел к нам, сейчас трудится над платформой.
— Главное, чтобы мы нашли общий язык. Еще очень важна самостоятельность — чтобы сотруднику не требовался постоянный саппорт. Этим как раз старший разработчик и отличается от младшего: первый может самостоятельно решать сложные задачи, а второму требуется помощь.
Но, к сожалению, самостоятельность практически нереально проверить на собеседовании. Да, можно понять скилл решения проблем — например, с помощью непростой алгоритмической задачи. Но самостоятельный человек или нет, можно узнать только в процессе работы. И зачастую бывает так, что хорошие технические специалисты, которые много знают, не обладают этим навыком.
— Я с детства увлекался математикой, как и многие другие разработчики. Попал в физматшколу МГУ и уже тогда планировал, что пойду в разработку. После школы поступил на профильный факультет — ВМК МГУ. Там я уже более серьезно занялся программированием и на третьем курсе начал работать. На четвертом — вышел на фултайм. Мне нравится разработка, другого для себя вообще не рассматривал.
— Вообще да. Месяцами на четвертом и пятом курсах я работал без выходных, ездил на учебу в рабочие дни. Зато это помогло стать тимлидом команды уже через год после окончания университета. В «Лабораторию Касперского» я пришел на должность senior-разработчика, потом стал тимлидом и менеджером.
— Зачастую разработчики — интроверты и им сложно перестроиться с индивидуальной работы на управление людьми. Как прошел переход у тебя?
— Я не интроверт, наоборот, рад общению, и работать менеджером мне довольно легко. Мне нравится быть тимлидом: можно сделать куда больше, задачи — сложнее и амбициознее, это доставляет огромное удовольствие.
— Если говорить о менеджерских функциях, ты следишь за работой подчиненных? Как разбираешься с потоком задач на отдел? Проверяешь качество выполнения?
— У меня есть несколько команд, где руководят менеджеры и одна небольшая, где я — непосредственно проджект-менеджер. С менеджерами, которые у меня в подчинении, мы работаем «по целям»: оговариваем критерии, по ним строим план работы и проверяем ее выполнение. У моей же продуктовой команды есть обычный план работы и бэклог с важными задачами и приоритетами. Мы работаем двухнедельными итерациями. Берем задачу, стараемся выполнить. Раз в неделю — планерки. Наша команда самостоятельная, и многие проблемы нам удается решить без привлечения руководства.
— Бывают ситуации, когда нужно выйти и закрыть проект. Но это происходит редко — когда выходит релиз фронтов с большим количеством изменений и доработок.
— Когда я только начинал, релизы фронтов были более сложным мероприятием, чем сейчас. Мы активно развиваем автоматизацию процессов и тестирования и сейчас все проходит заметно быстрее. Жизнь разработчика упростилась, я бы так сказал.
— Как раз в следующий релиз фронта. К тому моменту мы переделали бизнес-логику анализа сетевого траффика: полностью переписали ее. Работа заняла чуть меньше года, и мы очень неплохо справились: избавились от огромного пласта legacy-кода и перевели продукт на новые рельсы. Это был реальный челлендж.
— Обычно разработчики начинают день с просмотра писем, вопросов, которые накопились с вечера или раннего утра. Все задачи в продуктовых командах идут через систему тикетов, сотрудник выбирает себе нужные и занимается ими.
Главный инструмент — С++, основной код и движки у нас на нем. Решение задачи состоит из обычных этапов: написания кода, локальное тестирование и отладка, код ревью, автотестирование в системе CI и деливери доработок в продукты.
— Есть ряд приложений, для которых мы поставляем базовые компоненты. Они написаны на С++. Дальше компоненты используются уже в нативном формате, портировать их можно без проблем. Вообще большинство high performance приложений или игр, в AppStore или в Google Play, написаны на С++, — если и не полностью, то большая часть приложения точно. Скорее всего, те же Angry Birds или Cut the Rope. Продукты С++ работают быстрее, чем на Java или Swift — так как это высокоуровневые языки с «дорогими» абстракциями и виртуальной машиной.
— А если человек хорошо знает, например, Java? Можно ли его переучить или проще взять спеца именно по C++?
— У нас в команде есть разработчики кода и разработчики автотестов. И мне очень хочется объединить эти роли в одну. Одни разработчики пишут много маленьких тестов (Unit-тестов), а другие спецы пишут крупные интеграционные. Возникает определенное недопонимание: периодически одни профессионалы не очень понимают специфику огромных интеграционных тестов, а другие не очень хорошо знают код, который тестируют. Отсюда случаются ситуации, когда ругались то на код, то на тесты.
Мне это не очень нравится: роли хочется сблизить, чтобы сотрудники могли одновременно писать код и работать над тестами любого уровня. Плюс, выделить отдельную роль чисто по инфраструктуре, фреймворкам. Глобально вот такая идея развития.
— У нас есть несколько свободных позиций, связанных с разработкой компонентов сетевого анализа. К слову, я там начинал. Не хватает людей и в команде, которая работает над драйверными компонентами системного перехвата. В целом задач много, они сложные, но интересные!
- Мы постоянно пытаемся совершенствовать наши решения. Например, мы переделываем систему распространения наших драйверов в продуктах. В установках драйверов куча подводных камней: обновления, откаты операционных систем. На это накладываются наши патчи. В результате получается не очень детерменированный стейт, который мы хотим сделать более предсказуемым. По пути решив проблему с выпуском патчей для новых версий ОС.
- Мы делаем очень большой упор на новые продукты. Мы понимаем, что антивирус не вечен, нельзя бесконечно «пилить» его и быть успешными. Тут — решение задач в различных новых для нас направлениях и продуктах, таких как Anti Targeted Attack Platform, развитие новых десктоп-приложений.
- У нас довольно много инфраструктурных задач по сборке и автотестированию большого объема кода. Мы хотим, чтобы каждый коммит в наш код проверялся (собирался и запускал тесты) на всех продуктах за пару десятков минут.
- Ну и всегда актуальная задача — делать код высокопроизводительным. Например, мы очень хотим сделать антибаннер не только большим с точки зрения покрытия, но и еще менее тормозным, как классические расширения.
— Мажорные версии продуктов с кучей фич — например, тот же Kaspersky Internet Security, выходят, в среднем, раз в год. Но у нас много патчей, и зачастую работа над ними — чуть ли не как отдельная разработка. Вот, например, смотрите, сейчас Microsoft раз в полгода выпускает апдейт для Windows. По факту он как новая операционка — слишком много изменений в ядре. Для нас каждый такой апдейт равносилен выходу новой ОС с полноценной разработкой продукта под нее. Для меня это как челлендж: раз в полгода выкатить поддержку для новой «винды». Но каждый раз нашей команде это удается!
— В первую очередь, чтобы правильные и нужные вещи делались легко, а не правильные и не хорошие — долго и мучительно (тогда их не будут делать). Например, мы сейчас уходим от компонентной разработки.
Здесь подход такой: отдельно разрабатываются стабильные интерфейсы и реализовываются компоненты с данными интерфейсами, затем связываются и вроде бы все замечательно. До того момента, пока интерфейсы не начнут меняться. Условно говоря, есть первая версия компонента, которую используют все. Затем появляется вторая версия, с доработкой или изменением API. Одни продукты на него переходят, а другие — нет. А потом всем вдруг нужно перейти на новый компонент. В такой ситуации сложно подсчитать ресурсоемкость переезда, плюс нужно будет чистить баги — это очень большой и дорогой интеграционный момент.
Поэтому мы хотим изменить подход и перейти в так называемый монорепозиторий с зелеными тестами. Его суть проста: когда изменяется интерфейс, его нужно сразу проинтегрировать во все продукты. При этом мы поддерживаем тотальную валидацию: каждый коммит должен переводить систему из зеленого состояния тестов в зеленое состояние, иначе коммит уберется.
Другими словами, раньше, до отхода от компонентной разработки, интерфейс можно было исправлять только в рамках одного проекта. Сейчас мы можем вносить изменения одновременно по всем проектам. В итоге продукт быстрее доходит до стадии релиза. И сам процесс становится более предсказуемым.
— Скорее, систему доставки в прод. Мы не будем выстраивать многоступенчатую сборку, а автоматизируем ее.
В принципе это основное, что касается разработчиков. Для менеджеров новая система детерминирует риски использования нового кода, которые будут всегда актуальными.
— На собеседовании вы сразу, через тестовые задачи, погружаете человека в то, чем ему придется заниматься?
— Нет, такого нет, у нас абстрактные задачи, не привязанные к нашей проблемной области. На базовое понимание.
— Case-by-case. «Синьоры» более самостоятельны, им опека не нужна — наоборот, будет мешать. А junior-ам, конечно, помогаем — для каждого назначаем ментора, который сможет объяснить и подсказать по задачам. Но вообще все зависит от человека: мы стараемся создать максимально комфортные условия для каждого. И людям у нас нравится: обычно они остаются у нас на много лет.
К тому же, у нас есть программа адаптации для новичков, которая состоит из нескольких этапов. Каждые две недели здесь проходят трехчасовые вводные встречи для таких сотрудников. Их знакомят с историей компании, продуктовой линейкой и руководством, рассказывают о том, как устроена наша жизнь. Например, как оформить отпуск, уйти на больничный, что делать, если возникла проблема с компьютером, какие есть правила безопасности в офисе и так далее. Важные и полезные вещи.
— У нас гибкий рабочий график, можно поработать из дома, если приболел или что-то случилось, — для этого есть удаленный доступ. Но постоянно работать удаленно нельзя, нужно общаться с клиентами и тимлидом.
— Очень и очень плотное. Продакт-менеджеры сидят рядом с разработчиками, в соседнем опенспейсе-кубике (у нас пространство в офисе с помощью оформления поделено на небольшие «кубики», где обычно сидят по 4-6 человек). Для нас важно постоянно взаимодействовать друг с другом, мы очень близко, в одной команде, все общаемся между собой.
— За время работы в компании я занимался несколькими направлениями. Но все они так или иначе связаны с перехватом трафика и его анализом. Я уже говорил про переписывание бизнес-логики перехвата в наших дестоп-продуктах. После этого много времени я посвятил улучшению технологии безопасных платежей. Это функциональность по защите онлайн-операций пользователя. Изначально функциональность выглядит просто — при переходе на сайт банка или совершении иных финансовых онлайн операций нужно включить функционал и предотвратить любое вмешательство. Но проблемы случаются, как всегда, во время реализации. Нам оказалось сильно проще и эффективнее запустить новый браузер вместо защиты уже работающего и проконтролировать, чтобы в него никто не попал. С таким решением существует много минусов, но основной — это перенос контекста работы из обычного браузера в нашу защищенную копию. Например, пользователь заходит в личный кабинет провайдера и хочет оплатить интернет. Мы понимаем, что сейчас будут вводить данные в платежной системе и переносим сеанс в защищенную копию, но теряем факт логина в личный кабинет. Еще одна сложная задача — это определение самого факта начала финансовой операции. Просто по адресу это понять нельзя, так как много всяких картинок и остального CSS выкачивается браузерами. Поэтому нужно анализировать контекст.
— А свобода творчества у сотрудников есть? Могут запилить свой продукт в рамках продуктов «Лаборатории Касперского»?
— Выделить рабочий день на сторонние проекты, как в Google, не получится — мы живем в рамках бизнеса. Но в рамках компании, работающей в сфере кибербезопасности, можно что-то придумать и получить поддержку. Ведь часто возникает мысль: «О, мы можем защитить вот это». И приходит разработчик с proof-of-concept, предлагает сделать новую защищенную технологию, новый продукт. И мы делаем.
У нас есть защита видео, опять же, safe-браузер начинался как обычный контейнер. Это все шло от концептов разработчика, а бизнес это принял и дал зеленый свет для реализации.
Приложение для мобильных устройств «Who Calls» тоже продвигали как идею одного из менеджеров. Звонки с неизвестных номеров и спам были его личной проблемой, и ее решение он воплотил в продукте. И сейчас активно его развивает, получает от нас фидбэк.
У нас есть защита UEFI: разработчик купил новый компьютер, а там программируемый BIOS. Сотрудник разработал proof-of-concept и предложил написать антивирус, который будет проверять загрузочную область. Идея понравилась, под нее выделили разработчиков. Недавно продукт выпустили, он продолжает развиваться и живет своей жизнью.
Здравствуйте! Мы подразделение «Лаборатории Касперского», которое разрабатывает безопасную операционную систему KasperskyOS. Наша цель — создать ОС, у которой есть кибериммунитет, поэтому ей не страшно доверить управление умными автомобилями, сложными техническими процессами и важными информационными системами.
Хотим рассказать, как идет развитие проекта, какие технологии лежат в его основе и что получается на выходе. Ну и немного о нашей внутренней структуре: кто и чем занимается, как выстраивается работа на удаленке, а также как попасть к нам в команду.
Может показаться, что в мире существуют ОС под любые задачи. Есть операционки общего назначения, такие как Windows, macOS или дистрибутивы на базе ядра Linux. Есть специализированные — для авиации и промышленности, с real-time-характеристиками и доказанной надежностью. Но полностью безопасных нет.
Обычно меры защиты разрабатываются в ответ на существующие или потенциальные известные угрозы. Но этот подход не дает 100% гарантий. С завидной регулярностью возникают новые классы угроз, которые разработчики не принимали в расчет.
Классический пример — техника возвратно-ориентированного программирования (return-oriented programming). Еще совсем недавно считалось, что исполнение вредоносного кода станет невозможным, если выполнить 2 условия:
- запретить исполнение кода в областях, куда могут попасть пользовательские данные;
- защитить от модификаций области памяти, где находится программный код.
Это не помешало хакерам и исследователям в области безопасности найти способ обойти защиту. Оказалось, что с помощью подмены адреса возврата из процедуры и используя части кода самого приложения и системных библиотек можно выполнить сложные действия и получить результат, который требуется злоумышленнику.
Мы в «Лаборатории Касперского» решили подойти к проблеме радикально: разработать подход, обеспечивающий надежную защиту от любых атак — как известных, так и перспективных. Изначально мы не ставили себе цель сделать новую операционную систему и рассчитывали, что задачу можно решить, используя уже разработанные ОС.
Для начала немного теории. Как понять, безопасно решение или нет? Нужно с самого начала установить цели безопасности — требования, выполнение которых должно обеспечиваться при любых сценариях работы системы. Следовательно, в безопасном решении нужно сделать невозможным выполнение любых операций, способных повлиять на достижение целей безопасности.
Принцип очень простой: в процессе работы решения нужно проверять, способна ли та или иная операция негативным образом повлиять на безопасное функционирование системы, и если да, то такую операцию необходимо блокировать. Однако есть 2 сложности: нужно понять, какие операции надо контролировать, и оценить влияние этих операций на безопасную работу системы.
Начиная с 70-х годов прошлого века ведется активная разработка принципов создания безопасных систем, разрабатываются формальные модели разделения решений на домены с различным уровнем доступа.
В дальнейшем, к началу двухтысячных, когда технологии доросли до требований, предъявляемых теоретическими концепциями, получил развитие подход Multiple Independent Levels of Security (MILS). Он предусматривает разделение системы на изолированные домены безопасности и контроль всех операций, связанных с передачей данных между доменами. На этом подходе базируется большинство современных систем, к которым предъявляются высокие требования к безопасности и надежности их работы.
Представим набор полностью изолированных программных компонентов. Они безопасны, пока не взаимодействуют друг с другом и окружающим миром. Ни кривой код, ни уязвимости в этих компонентах не страшны системе. Однако на практике полная изоляция бессмысленна и не нужна. Для выполнения функциональных задач различные компоненты ПО должны взаимодействовать как между собой, так и с внешним миром. Но чтобы поведение системы оставалось безопасным, все взаимодействия компонентов должны проводиться под контролем. Как это организовать?
Первое: нужно предоставить гарантии изоляции компонентов друг от друга. В MILS-системах за эту задачу отвечает ядро разделения (Separation Kernel). Обычно эту функцию выполняет микроядро или гипервизор.
Второе: нужно строго описать, как каждый программный компонент может взаимодействовать с другими. Тогда в результате появится возможность перечислить все подлежащие контролю операции.
Третье: создать в системе компонент-медиатор, через который будут проходить абсолютно все взаимодействия. Тогда у него будет возможность разрешать безопасные операции и запрещать опасные. Решение о том, какая операция является безопасной, принимается отдельным компонентом — вычислителем вердиктов безопасности (Policy Decision Point).
Впервые отделить логику вычисления вердиктов (Policy Decision Point) от их применения (Policy Enforcement Point) было предложено в 90-е годы в рамках проекта Flux Advanced Security Kernel (FLASK). На подходах, разработанных в рамках этого проекта, базируются многие решения в области безопасности, например, SELinux.
При вычислении вердикта нужно принимать в расчет сведения об особенностях реализации решения, о контексте, в котором выполняется операция, о целях безопасности и т. д. Для доказательства корректности взаимодействия компонентов можно вынести за скобки всю их внутреннюю активность — они изолированы, и им запрещено все, что явно не разрешено.
У нас есть декларация интерфейса взаимодействия, включающая описание всего, что необходимо для понимания специфики операций. Если найти способ преобразовать эти данные в параметры моделей безопасности, появится возможность задавать формальные политики безопасности с учетом особенностей каждого конкретного решения.
Policy Decision Point принимает решения, от которых зависит безопасность всей системы, поэтому мы должны быть полностью уверены в чистоте и безошибочности его кода. Правила вычисления вердиктов должны быть однозначны и математически корректны.
Воплощая эту концепцию в жизнь, мы создали специальный компилятор. Он принимает на вход декларативные описания взаимодействующих компонентов и конфигурацию безопасности.
Результат работы компилятора — программный код на языке C, определяющий функциональность Policy Decision Point. У автоматически генерируемого кода есть несколько преимуществ:
- Доверие к такому коду выше, чем к написанному вручную. Например, вместе с кодом, сгенерированным на основе формальной модели, можно сгенерировать и набор тестов, проверяющих его соответствие модели. Упрощается и процесс формального доказательства определенных свойств полученного кода, например, предельного времени выполнения.
- Становится возможным использовать простые наборы правил взаимодействия компонентов. Корректная работа правильно спроектированной системы предполагает лишь малое число стандартных потоков исполнения, которые требуется описывать. В то же время правила вычисления вердиктов могут быть сложными и разнообразными — это уже забота компилятора.
- Инженер безопасности описывает поведение системы в терминах, с применением которых она была спроектирована. Есть возможность всесторонне учесть специфику решения.
- Описание безопасности выполняется независимо от бизнес-логики решения.
Так появился движок, который выполняет вычисление вердиктов безопасности, — Kaspersky Security System (KSS).
По сути, KasperskyOS — это идеальная специальным образом оптимизированная среда для работы KSS. Расскажем, почему мы не стали использовать существующие ОС в качестве такой среды.
Например, на базе Linux создано несколько механизмов и модулей безопасности: SELinux, AppArmor, GR security, SMACK, контейнеры и т. д. Однако все они оказываются бесполезными, когда скомпрометировано ядро ОС. Linux — классическое монолитное ядро, где все компоненты работают в одном адресном пространстве и могут влиять друг на друга. Да, код ядра Linux просматривают миллионы глаз, но по-настоящему тщательной ревизии подвергаются только наиболее ответственные компоненты ядра. В ядре Linux более 15 млн строк кода, и значительная его часть остается вне зоны пристального контроля Linux-сообщества. В результате часто обнаруживаются критичные уязвимости, эксплуатация которых позволяет скомпрометировать ядро Linux. Тем самым не реализуется главное требование по обеспечению безопасности — изоляция между доменами. Кардинально поменять архитектуру Linux вряд ли получится, уж если у Таненбаума не получилось переубедить Торвальдса, то у нас и вовсе шансов нет :)
Что же с существующими микроядерными операционными системами? Ядро в таких системах обычно весьма компактно и благодаря этому лишено описанных выше недостатков, свойственных монолитным и гибридным архитектурам. Микроядра идеально подходят для создания ядер разделения в MILS-системах. Более того, есть несколько хороших защищенных микроядерных операционных систем с открытым исходным кодом, например, seL4.
Несмотря на все плюсы использования готового микроядра, мы пришли к выводу, что возможности существующих систем в области безопасности недостаточны для реализации нашего подхода. Обычно создатели ОС пытаются контролировать доступ к ресурсам. Именно ресурсами в первую очередь оперирует модель безопасности object-capability, которая используется в большинстве микроядерных операционных систем. Дальнейшие более изощренные свойства безопасности реализуются в виде прикладной логики. Возможности политик безопасности будут сильно ограничены, если мы возьмем только модель object capabilities.
Таким образом, оказалось, что использование готовых ОС не позволяет реализовать идеальную среду для работы KSS так, как мы ее видим. Поэтому и пришлось разрабатывать новую операционную систему.
Помощь правоохранителям и рост доходов
В том же году в компании появился департамент расследования компьютерных инцидентов. Он успешно участвовал в около 330 расследованиях преступлений в сфере кибербезопасности. На безвозмездной основе оказывалась всесторонняя помощь правоохранительными органам.
К 2013 году неаудированный годовой доход возрос до 667 миллионов долларов. Спустя год было подписано дистрибьюторское соглашение с Ingram Micro. Это значительно расширило программу реселлеров «Лаборатории Касперского». Была также запатентована новая технология сравнения файлов.
В 2016 году корпорация объявила, что намерена делать инвестиции в перспективные стартапы. Заявленная сумма составляла от 50 тысяч до 1 миллионов долларов. В штаб-квартире был открыт корпоративный ресторан «БарKas», который стал пользоваться определенной популярностью.
Рождение бренда
Сам Евгений не хотел, чтобы фирма носила его имя, но партнеры смогли его убедить.
Спустя полтора года после основания бренда, в Великобритании открылось первое зарубежное представительство Kaspersky Labs UK. К этому времени он смог увеличить свою долю на российском рынке антивирусного программного обеспечения с 5 до 50%. Одной из причин стало предоставление по тем временам уникального для нашей страны сервиса — круглосуточной техподдержки. Бренд предоставил также пользователям своего антивируса регулярное обновление ПО, которое стало ежедневным с 20 марта 2000 года.
Трамп против «Касперского»
В конце 2017 года американский президент Дональд Трамп подписал закон, запретивший государственным учреждениям США устанавливать на свои ПК ПО Kaspersky lab. Решение было аргументировано тем, что такие программы могут применяться российскими спецслужбами для получения доступа правительственным документам США. В ответ российская компания подала в суд и в то же время объявила о шагах, направленных на восстановление доверия к своим продуктам в США и в Европе. В числе таких мер было анонсирование центров прозрачности не только в Соединенных Штатах, но и в Европе и Азии. Кроме того, “Лаборатория” обещала раскрыть коды своих продуктов для независимого аудита зарубежным регуляторам.
Читайте также: