Книга: Руководство по DevOps

Статическое тестирование безопасности в компании Twitter (2009 г.)

Презентация 10 Deploys per Day: Dev and Ops Cooperation at Flickr, подготовленная Джоном Оллспоу и Полом Хэммондом в 2009 г., известна тем, какое масштабное влияние она оказала на сообщество DevOps. Ее эквивалент для сообщества информационной безопасности — по-видимому, презентация Джастина Коллинса, Алекса Смолина и Нила Мататала, представленная на конференции AppSecUSA в 2012 г. В ней рассказывалось о трансформации работы над защитой данных в компании Twitter.

Из-за стремительного роста у этой организации появилось много проблем. На протяжении многих лет, когда у сайта не было достаточного количества ресурсов, чтобы соответствовать высокому спросу пользователей, на экран выводилась страница с сообщением об ошибке. На ней был нарисован кит, поднимаемый в небо восемью птичками. Масштаб роста числа пользователей поражал воображение: между январем и мартом 2009 г. число активных пользователей Twitter выросло с 2,5 миллиона до 10 миллионов человек.

У компании в этот период также были и проблемы с безопасностью. В начале 2009 г. произошло два серьезных инцидента. В январе был взломан аккаунт @BarackObama. Затем, в апреле, с помощью словарного перебора были взломаны аккаунты администрации Twitter. Эти события привели к тому, что Федеральная комиссия по торговле США приняла решение о том, что организация вводила своих пользователей в заблуждение относительно безопасности их аккаунтов, и издала соответствующее распоряжение.

Согласно этому распоряжению, компания должна была в течение 60 дней ввести несколько мер, а затем поддерживать их 20 лет. Среди этих мер были:

• назначение сотрудников, ответственных за план информационной безопасности компании;

• определение относительно предсказуемых рисков, как внутренних, так и внешних, приводящих к несанкционированному проникновению, а также создание и воплощение плана по сокращению этих рисков[163];

• защита личной информации, причем не только от внешних источников, но и от внутренних, с примерным планом возможных источников верификации и тестирования безопасности и правильности этих реализаций.

Группа инженеров, назначенная для решения этой проблемы, должна была сделать защиту данных частью повседневной работы разработки и эксплуатации и закрыть дыры в системе безопасности — причины взломов аккаунтов.

В уже упоминавшейся презентации Коллинс, Смолин и Мататал определили несколько насущных проблем.

• Предотвратить повторение ошибок в сфере безопасности: они обнаружили, что на самом деле они снова и снова исправляли все те же дефекты и уязвимые места, что и раньше. Нужно было так изменить инструменты автоматизации и всю систему работы, чтобы эти проблемы перестали повторяться.

• Встроить цели безопасности в уже существующие инструменты разработки: они определили, что основным источником уязвимости были проблемы с кодом. Использовать какой-нибудь инструмент, выдающий огромный PDF-отчет, затем отправляющийся разработчикам или инженерам эксплуатации, было нерационально. Вместо этого требовалось средство, сообщающее конкретному разработчику, создавшему конкретную уязвимость, точную информацию, необходимую для устранения проблемы.

• Сохранить доверие разработчиков: им надо было заслужить и сохранить доверие разработчиков. Это означало, что требовалось узнавать о случаях, когда они посылали разработчикам неверную информацию, чтобы стало возможным разобраться в причинах ложного срабатывания и впоследствии не тратить зря время разработчиков.

• Поддерживать быстрый поток в информационной безопасности с помощью автоматизации: даже когда сканирование кода на наличие уязвимых мест было автоматизировано, службе безопасности все равно приходилось делать много работы вручную и тратить время на ожидание. Нужно было ждать завершения сканирования, получить большую стопку отчетов, интерпретировать результаты и затем найти ответственного за исправление недочетов. А когда код менялся, нужно было проделывать все с самого начала. Автоматизируя работу вручную, сотрудники выполняли меньше примитивных задач, сводящихся к бездумному нажатию кнопок, и могли тратить время на более творческие задачи.

• Отдать все, что связано с защитой данных на самостоятельное обслуживание, если это возможно: они верили, что большинство специалистов хотят работать как можно лучше, поэтому нужно дать им доступ ко всему контексту и всей нужной информации, чтобы они могли сами исправлять ошибки.

• Принять целостный подход к защите данных: их целью был анализ со всех возможных точек зрения: исходный код, среда эксплуатации и даже то, что видели их клиенты.

Первый большой прорыв произошел во время общеорганизационного недельного хакатона, когда они интегрировали статический анализ кода в процесс сборки. Команда использовала Brakeman, сканирующий приложения Ruby on Rails на наличие уязвимых мест. Целью было встроить сканирование в самые ранние стадии разработки, а не только проверять итоговый код, отправляемый в репозиторий.

Результаты интеграции тестирования в процесс разработки были потрясающими. За год благодаря быстрой обратной связи о небезопасном коде и о способах его корректировки Brakeman сократил долю обнаруженных уязвимых мест на 60 %, как показано на рис. 44 (пики обычно соответствуют релизу новой версии Brakeman).

Рис. 44. Число уязвимых мест в системе безопасности, обнаруженное Brakeman

Оглавление книги