Каким должно быть предположение для сетевого проекта?

«Предположения» — тонкое понятие. Я бы посоветовал вам рассмотреть все факторы, которые могут повлиять на успех вашего проекта.

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

• если вы не можете управлять фактором, относитесь к нему как к риску - оцените вероятность/частоту/воздействие и смягчите те, которые можете. Первым шагом в управлении рисками является сбор достаточной информации для проведения оценки.

• если вы не можете оценить фактор - если просто слишком много неизвестного, то сделайте предположение. После того, как вы сделали предположение, задокументируйте риск. Предположения — это (грубо говоря) риски, которые слишком дороги для оценки с какой-либо степенью достоверности. Это может быть связано с тем, что информация, необходимая для оценки качества, еще недоступна, или это может быть связано с фундаментальными разногласиями в команде проекта, или может быть просто сбор и систематизация информации для создания хорошей оценки потребует времени. /усилия, недоступные на данном этапе. Каждое предположение — это риск

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

Преимущество этого подхода (допущения, управляемые как риски) заключается в том, что вы избегаете документирования тривиальных и неуправляемых допущений. (Я предполагаю, что в ходе этого проекта Солнце не превратится в новую звезду; это предположение, но управление рисками немедленно классифицирует его как не подлежащее дальнейшему анализу.

Пример 1: Вы указали, что клиент очень обеспокоен безопасностью. Враждебная мотивация и возможности часто являются предположениями. Вы не контролируете противника. Если в вашей организации нет сильной функции анализа угроз, ее очень трудно измерить. Но вы можете делать предположения о классах противников — в основном по матрице 2x2, сравнивая ресурсы и нацеливание — вы будете по-разному защищаться от целей с высокими ресурсами и низкой точностью, таких как преступные заговоры, чем от высокоточных субъектов с низкими ресурсами, таких как киберактивисты.

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

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

1. У злоумышленников не будет ресурсов национального государства. (Защита от национального государства требует совсем другого уровня ресурсов). Злоумышленники будут больше похожи на X. (Это может быть встроено в набор предположений о силе и мотивации злоумышленника; зависит от сложности анализа угроз вашего клиента).

2. Информация, хранящаяся в сети, будет не более ценной, чем X (тесно связанная с предыдущей) — у меня был слишком большой опыт работы с сетями, построенными для защиты информации типа X, и пользователи настаивали на истории типа Y. Как только количество Типа Y информация в сети становится достаточно большой, злоумышленники начинают интересоваться. Чаще всего это происходит, когда пользователи настаивают на хранении PII в сети.

3. Агентство-владелец имеет/не имеет политики агрегирования информации. (в некоторых случаях факт X не является конфиденциальным, но если вы агрегируете N экземпляров факта X, информация становится конфиденциальной). Это классический случай того, что вы не контролируете, но должны управлять.

4. WEP2 устойчив к предполагаемым злоумышленникам в течение как минимум 5 лет.

5. Наш поставщик сертификатов продолжает обеспечивать надлежащую безопасность сертификатов (безопасность сертификатов включает людей, процессы и технологии; как пользователь/клиент сертификата, все, что вы можете сделать, это следить за тем, чтобы они проходили периодические проверки).

6. В моей сети нет скрытых каналов, или скрытых каналов недостаточно. ( Раньше это было неясно, но SPECTER & BEAST доказали обратное).

7. Любая федеративная аутентификация или контроль доступа своевременно информируют нас об атаках.

8. Подключенные сети правильно передают информацию о своем риске, остаточном риске, управлении рисками и атаках/инцидентах. (Еще один большой случай информации, которую вы не контролируете, но которая влияет на ваш успех). Помните фиаско Target network? Ваша миссия может потребовать от вас подключения к сторонней сети; если они лгут о своей информационной безопасности, или о своей транзитивной связности, или о степени их взлома, это может серьезно повлиять на вашу безопасность.

9. Безопасность будет адекватно финансироваться.

• (это не заявление о вашем проекте — это заявление о безопасности, на которую вы полагаетесь. Например, SIEM/управление инцидентами обычно является аутсорсинговой функцией, которую вы не контролируете; ваш успех зависит от них. Например , если вы планируете на основе круглосуточной работы персонала с интервалом обнаружения 1 час и 80-процентной достоверностью обнаружения вторжений менее 1 недели, то вы обнаружите, что их финансирование было сокращено, и они будут укомплектованы в дневную смену сотрудниками, у которых значительно меньше квалификации, то вам необходимо пересмотреть свои предположения.
• это также шаблон для любой услуги, которая передается на аутсорсинг, любой услуги, на которую вы полагаетесь.

1. Каждое соглашение об уровне обслуживания безопасности представляет собой набор предположений об отношениях между вашей сетью и другой сетью. Каждый Меморандум о взаимопонимании, каждое Соглашение о присоединении и т. д. Очень немногие сети тратят время и усилия, оправданные здесь. Как часто вы используете SSLA/MOU/ICA? Как часто ваши партнеры проходят аудит и какой частью этой информации они делятся с вами. (Одним из моих любимых воспоминаний было управление сетью, которая полагалась на сетевого провайдера; сетевой провайдер запретил нам просматривать какие-либо данные тестирования безопасности. Мы даже не могли увидеть их пакет авторизации или их политику безопасности. Признаки большой опасности. потому что они не реализовали свою безопасность - все это было обманом.)

2. Реализация безопасности будет соответствовать политике безопасности. (Все мы сталкивались с ситуациями, когда сетевая команда хвастается купленными ими причудливыми брандмауэрами, но когда вы видите брандмауэр, он подключен к источнику питания, но не к сети. Или он подключен, но пароль администратора используется всеми команда из 20+ и нет управления конфигурацией, или...)

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

4. Вы можете построить ряд предположений из старых предположений Оранжевой книги.

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

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

• Ресурсы будут доступны по мере необходимости (люди / финансы / материалы / оборудование и т. д.)
• Структура проекта будет такой, чтобы существовал четкий путь для эскалации проблем и рисков;
• Ответственность за закупку оборудования будет четко определена и доведена до сведения проектной группы;
• Команда будет размещена в (определенном месте) (или в любом другом месте);
• Конечные результаты четко определены, и любые их изменения подлежат официальному контролю изменений;
• Утверждение любых рекомендаций будет дано в течение согласованного периода (например, 3 дня), в противном случае сроки реализации проекта сдвинутся;
• Интеграция с существующими технологиями будет осуществляться (названной командой или лицом);
• Все технические стандарты будут определены и задокументированы; проект должен всегда соответствовать им;
• Ответственность за технический дизайн лежит на (названном лице или команде);
• ...и т.д. и т.п.

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