Упражнения

Цель данных упражнений – помочь понять концепции, изложенные в этой главе. Запишите ответы и посмотрите, какие вопросы вызвали затруднения: возможно, вам стоит перечитать главу. Такие упражнения будут в конце каждой главы. Незнакомый термин можно посмотреть в глоссарии в конце книги, что также позволяет облегчить понимание материала.

Если у вас есть коллега или профессиональный наставник, с которым вы можете обсудить ответы, это будет лучшим способом выяснить, правы вы или нет и почему. Некоторые из вопросов не являются логическими выражениями (не требуют ответов «истина/ложь»), а просто заставляют вас задуматься над проблемой.

1. Боб установил в настройках Wi-Fi на кардиостимуляторе запрет на передачу имени своего Wi-Fi. Как называется эта стратегия обеспечения безопасности?

2. Назовите пример значения, которое может быть жестко закодировано, и объясните почему. (Почему программист сделал бы это?)

3. Является ли капча удобной мерой безопасности? Почему?

4. Приведите один пример хорошей реализации удобства и безопасности.

5. Необходимо ли подтверждать данные, полученные при использовании параметров URL? Почему?

6. Если на работе сотрудник узнает коммерческую тайну, а затем продаст ее конкуренту, какую часть (или какие части) триады CIA он нарушит?

7. Вы купили смарт-холодильник и подсоединили его к домашней сети. К нему подключился злоумышленник и в настройках повысил температуру, в результате чего ваше молоко испортилось. Какую часть (или какие части) триады CIA он нарушил?

8. Если злоумышленник взломает ваш умный термостат и отключит отопление, какую часть (или какие части) триады CIA он нарушит?

9. Считается ли инсайдерской угрозой добавленная программистом «пасхалка» (дополнительный код, выполняющий незарегистрированные функции, в качестве «сюрприза» для пользователей, о котором неизвестно руководству и команде безопасности)? Почему?

10. Какие меры предосторожности можно предпринять при подключении к общественному Wi-Fi, чтобы обеспечить «глубокую защиту»?

11. Если вы живете в квартире с несколькими соседями и у каждого из вас есть ключ от двери, считается ли один из таких ключей «фактором аутентификации»?

Глава 2

Требования безопасности

Независимо от используемой методологии разработки (Waterfall, Agile, DevOps), языка, платформы или аудитории требования к любому приложению, к любому новому проекту должны быть определены. Без плана нельзя создать что-то стоящее.

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

Рис. 2.1. Жизненный цикл разработки системы

СОВЕТ. Жизненный цикл разработки системы называется также жизненным циклом программного обеспечения (ПО). Можно заметить, что во втором определении основное внимание уделено программному обеспечению, а не системе. Два этих определения взаимозаменяемы.

На первом собрании по проекту (часто называемом «установочной встречей») должен присутствовать человек из службы безопасности, который будет принимать участие в проекте с самого начала разработки. Даже не занимаясь проектом полный рабочий день, он должен быть полноценным членом команды и постоянно оказывать активную помощь в своевременном решении всех вопросов и проблем, касающихся обеспечения безопасности. Назначение сотрудника службы безопасности в проектную команду иногда называют моделью партнерства, а самого человека – «встроенным в матрицу команды». Независимо от того, как его называют, данный сотрудник должен представлять интересы службы безопасности (то есть триады CIA) на протяжении всей разработки проекта.

ПРИМЕЧАНИЕ. Точное происхождение термина «Модель партнерства» неизвестно. Впервые я узнала о нем от команды Netflix, занимающейся вопросами безопасности. Выражение «встроенный в матрицу команды» я впервые услышала в секретариате Казначейства Канады, и оно также имеет неизвестное происхождение.

В этой главе предполагается, что у вас есть базовое понимание работы IТ-проектов и процессов разработки программного обеспечения.

СОВЕТ. Определить разумные сроки ожидания ответа от службы безопасности можно с помощью соглашения об уровне поддержки (SLA, Support Level Agreement) между службой безопасности и другими командами. Часто во время работы над проектом взаимодействие с представителями службы безопасности становится практически невозможным. При наличии SLA этой проблемы можно избежать. Для достижения наилучших результатов следует установить скромные начальные цели и постепенно увеличивать их масштаб.

Требования

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

• Содержит ли система конфиденциальные, чувствительные или персональные данные (PII, Personally Identifiable Information – идентифицируемая личная информация) или контактирует с ними?

• Где и как будут храниться данные? Будет ли приложение доступно для общественности (находиться в интернете) или только для внутреннего пользования (находиться в интранете)?

• Выполняет ли приложение конфиденциальные или важные задачи (например, перевод денег, отпирание дверей или доставку лекарств)?

• Выполняет ли приложение какие-либо программные действия, сопряженные с риском (например, позволяет ли пользователям загружать файлы)?

• Какой уровень доступности необходим?

• Требуется ли 99,999 % времени непрерывной работы? (Примечание: практически ни одна система не требует такого уровня доступности.)

В идеале представитель службы безопасности должен задать необходимые вопросы и на основании ответов к ним добавить соответствующие пункты в общий список требований к проекту. Например, «Позволит ли приложение загружать файлы пользователям? Да? Хорошо, тогда добавим вот такие требования безопасности в спецификацию проекта, чтобы разработка с самого начала велась с учетом обеспечения безопасности».

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

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