Home

Автор: Маарет Пюхяярве (Maaret Pyhäjärvi)
Оригинал статьи
Перевод: Ольга Алифанова

На этой неделе, когда я начинала программу чемпионов BrowserStack со встречей участников вокруг костра-чата, что-то в разговоре о рабочих делах нажало во мне невидимую кнопку. Мы говорили о тестировании безопасности так, как будто это нечто новое и отдельное. На работе за безопасность у нас отвечают специальные люди, и годы опыта показали мне, что многие ожидают и подразумевают, что тестировщики мало знают о безопасности.

Те, кто сам тестировщик, любят отделять тестирование безопасности от функционального тестирования, а если их просят провести тестирование безопасности – думают только о тестировании на проникновение. Те, кто сам не тестировщик, любят расчищать пространство под безопасность, нанимая специалистов в этой области по принципу Ширки – специалистов, которые сберегут проблему, решением которой они являются.

Безопасность важна. Но, как и другие аспекты качества, она чересчур важна для специалистов. А то, что мы говорим о ней, выделяя ее единым термином "безопасности" или "тестирования безопасности", плохо, по моему опыту, влияет на наши усилия преуспеть в этой области.

Как и, впрочем, в тестировании, в безопасности мы работаем с рисками. В тестировании стоять на кону при принятии риска могут очень разные вещи. Сказать, что мы рискуем деньгами – это слишком в лоб. Мы рискуем:

• Свободными деньгами других людей, если ничего не предпримем.
• Собственными свободными деньгами, если ничего не предпримем.
• Деньгами, жизнями и страданиями людей там, где меры по исправлению не существуют.

Мы сосуществуем с чудовищным качеством ПО на проде, потому что множество имеющихся у нас якобы проблем связаны с первым пунктом, и могут достичь второго, но хоть потеря одного пользователя и печальна, других мы воображаем в масштабе. Слыша РИСК, мы слышим НАГРАДА за риск, и эта математика отлично работает, пока существуют меры по исправлению. К тому же соединение тестирования с плохими решениями в этой области – ну, такова жизнь (если предположить, что отстаивание багов приводит к тому, что компании, зная о проблемах, будут принимать верные решения). Я смотрю на это развитие событий 25 лет: наблюдаемые нами проблемы – не результат недостаточного тестирования, это результат того, что мы выбираем РИСК в надежде на НАГРАДУ. Так как риск – штука неопределенная, мы можем и выиграть.

Третья категория проблем уникальна. Я слышала о попытках оценить человеческую жизнь и страдания в деньгах, но это мне не особенно нравится. Сто евро компенсации жертвам кибермошенников, укравших записи психотерапевтов о клиентах – это просто смешно. Меня тревожит ограниченная ответственность компаний-банкротов. Суммы, которая полиция тратит на расследования, находятся вне нашего контроля. Ужас, что самые личные твои мысли станут известны всем, никогда не утихнет.

Не все проблемы безопасности относятся к третьей категории, но в вопросе избыточного акцента на тестировании безопасности меня расстраивает, что мы в принципе придаем мало значения третьей категории.

Несколько лет назад я отошла от тестирования безопасности максимально далеко, почувствовав себя под ударом из-за финского подкаста о безопасности. Тогда я написала статью, рассказав об иронии категорий "мои потери / потери компании", размышляя, что мои потери должны быть и потерями компании, стоит отправить им счет за мои профессиональные услуги. Однако небольшая группа безопасников решила, что то, что я столкнулась с багом, несущим потери для компании – это повод высмеять мой профессионализм. Я сообщила об этом как о клевете (преступлении), и узнала, что это не считается клеветой, и осадочек остался. Я потеряла деньги из-за бага: проблема тестирования. Компания потеряла деньги из-за бага: проблема безопасности. Меня волнуют обе.

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

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

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

Мы тестируем дизайн и внедрение безопасности. Моделирование угроз все еще остается деятельностью, объединяющей вопросы безопасности с исследовательским тестированием допущений, на которые мы полагаемся, принимая решения в этой области – и это прекрасная пара. Безопасное программирование – недопущение типичных для конкретного языка ошибок – возникает само собой, когда команды делятся друг с другом списками примеров. Работа с чем-то явным, в форме читабельного кода – это куда логичнее попыток удержать в голове все на свете одновременно, поэтому нам нужно и то, и другое. Безопасность – всего лишь один из факторов, где у нас есть возможность исследовать паттерны в теле кода.

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

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

Мы координируем реакции на новую информацию, внешняя и внутренняя коммуникация включительно.

Мы мониторим экосистему, чтобы знать, если потребуется наша реакция.

Мы понимаем юридические нюансы, а также причины для приватности, так как они влекут высокий риск в третьей категории: необратимые последствия.

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

Как можно видеть, беседы о тестировании безопасности ни к чему не приводят. Нам нужно больше слов, а не меньше. И нам нужно устранить путаницу и не предполагать, что абсолютно все проблемы безопасности очень важны – и точно так же не думать, что все функциональные проблемы не важны совершенно.

Обсудить в форуме