Краткое эссе о взаимосвязи между мерами кибербезопасности и ИТ-решениями с точки зрения бизнеса, которую часто неправильно понимают.
Часто я сталкивался с убеждением, что внедрение кибербезопасности на предприятии представляет угрозу для целей бизнеса. Однако известно и учат, что это не совсем правильно. На самом деле бизнес обычно является и должен быть основной силой, определяющей меры кибербезопасности . Разумеется, защита бизнес-активов отвечает первостепенным интересам бизнеса. Вопрос о том, какие меры являются достаточными, является вопросом пропорции. Но отношения более сложные, чем это.
Предприятие может быть более или менее склонным к риску. Уровень риска определяется потребностями конкретного бизнеса, а также общей стратегией предприятия, учитывающей опасения по поводу репутационного ущерба. Если вы хотите нести меньший риск, вам, скорее всего, придется вкладывать больше денег в кибербезопасность. Поэтому обычно мы думаем, что более высокий уровень безопасности означает соответственно более высокие затраты, и, кроме того, мы рассматриваем меры безопасности в целом как то, что препятствует скорости разработки, когда речь идет о выпуске типичных функций программного продукта.
Я не согласен с этим обобщением и негативным значением реализации мер кибербезопасности в отношении предоставления функций программных продуктов. Да, существующие продукты корпоративной безопасности дороги (например, антивирусное программное обеспечение). Да, написание или разработка безопасного программного обеспечения стоит дорого*. Да, соблюдение процессов безопасности требует много времени и средств. Да, сотрудников службы безопасности трудно найти. Но это не вся история взаимоотношений между кибербезопасностью и ИТ-решениями для бизнеса. Потому что во многих отношениях они идеально совпадают, поскольку разделяют одни и те же ценности: порядок, структура, документация и культура хорошего общения.
(*) Хорошо спроектированное программное обеспечение обязательно стоит дороже. Знаете поговорку: «программное обеспечение дорогое, качественное программное обеспечение дешевле»?
Качество программного обеспечения — это не только средство своевременной и бюджетной разработки бизнес-функций, но и прямой помощник в обеспечении кибербезопасности. Например, соблюдение принципов чистого кода приводит к снижению вероятности программных ошибок в целом, что, в свою очередь, предположительно снижает статистические шансы уязвимостей переполнения буфера (поскольку ожидается, что общее количество ошибок коррелирует с общим количеством ошибок переполнения буфера). уязвимости).
И наоборот, я считаю, что лучшие практики кибербезопасности могут положительно повлиять на ИТ-решения и, в частности, на качество программного обеспечения. Надлежащие меры кибербезопасности могут при определенных обстоятельствах даже ускорить реализацию (не связанных с безопасностью) функций программного продукта.
Я наблюдал две категории таких случаев, когда меры кибербезопасности оказывают положительное влияние на программный продукт ИТ-решения или процессы поддержки на практике: (1) меры кибербезопасности приводят к более ресурсоэффективной реализации (или использованию) ИТ. решение — например, меньшие затраты, необходимые для реализации функции — по сравнению с отсутствием каких-либо мер кибербезопасности, (2) внедрение расширенных мер кибербезопасности приводит к более эффективной реализации (или использованию) ресурсов. ИТ-решения, чем если бы были приняты хотя бы минимальные базовые меры безопасности. В следующих разделах я попытаюсь доказать, что утверждения (1) и (2) имеют смысл.
Я различаю случаи (1) и (2), так как их аргументация не одинакова. Случай (1) является более сильным утверждением, чем (2); случай (1) — это вопрос мира с кибербезопасностью по сравнению с миром без какой-либо кибербезопасности. Случай (2) предполагает, что меры безопасности уже реализованы, и вопрос заключается только в том, *сколько* и *какие* меры должны быть приняты.
Пример случая (1)
Когда-то я работал в очень крупной организации, многие программные приложения которой работали в облаке OpenShift (Paas). Когда вы разрабатываете свои приложения в облаке, таком как OpenShift, вам необходимо настроить облако в соответствии со своими потребностями. Обычно это включает в себя написание конфигураций развертывания для ваших приложений, а также (виртуальные) сетевые настройки или другие базовые настройки, такие как максимальное количество выделенных вычислительных ресурсов и отказоустойчивая избыточность среди наименьших. Как можно себе представить, для более крупных организаций такие облачные конфигурации могут стать довольно сложными. В организации, в которой я работал, обработка этих конфигураций стала на самом деле настолько сложной, что никто не знал, как настроить применяемые в настоящее время облачные настройки с нуля в разумные сроки, если это когда-либо понадобится.
Однажды должна была произойти облачная миграция от одного поставщика облачного хостинга к другому облачному провайдеру. Кому-то нужно было сделать дерьмовую работу: настроить группу странно вложенных скриптов, чтобы они соответствовали новому поставщику облачных хостов (URL-адреса и т. д.), выяснить порядок, в котором скрипты должны запускаться, выяснить, не упущено ли что-то. которых нет в существующих сценариях, добавьте то, чего не хватает, а затем проверьте, все ли по-прежнему работает в новом облаке после запуска всех сценариев (потому что никто не знал, отражают ли эти неподдерживаемые сценарии конфигурации текущего работающего облака). инфраструктура вообще). Было «невозможно» сначала реорганизовать комок спагетти, а затемвсе настроили, так как по словам команды «некогда было делать как следует» — типичная отговорка в проектах, где качество не так важно, как должно быть. Неудивительно, что миграция с одной облачной платформы на другую заняла целую вечность, потому что эти облачные конфигурации были вложены друг в друга и переплетены невообразимым образом. Среди прочего, жестко закодированные зависимости были «рассыпаны» по разным файлам и папкам. (Если у вас есть практический опыт в этой области, вы сможете полностью понять, о чем я говорю).
Несколько недель спустя управление безопасностью стало требовать, чтобы все программное обеспечение можно было установить в любом другом облаке в кратчайшие сроки, когда это необходимо (холодная площадка). Это хорошая практика аварийного восстановления. Аварийное восстановление является типичным требованием безопасности, которое управление безопасностью хотело улучшить за счет реализации быстрой и надежной готовности к настройке облака.
Чтобы выполнить запрос, связанный с безопасностью, команде пришлось выполнить ранее отложенный рефакторинг этого набора (спагетти) сценариев. Они собрали беспорядочные жестко запрограммированные строки, разбросанные повсюду, в одном месте и объединили все сценарии в несколько структурированных в одном месте. В мгновение ока они справились с этой приоритетной задачей. Теперь одна команда настроит все, где угодно и когда угодно, за считанные минуты.
Это было очень полезное мероприятие. В конце концов, это также помогло команде создать новое дополнительное облако специально для разработки за считанные минуты, чтобы они могли ускорить разработку, обеспечив каждому разработчику точное дублирование облака для определенных тестов, если это необходимо. Была обеспечена согласованность, улучшена тестируемость, сокращено общее обслуживание. Риски безопасности были снижены. Казалось, что оказание услуги по управлению безопасностью не было пустой тратой времени.
То, что архитектор безуспешно пытался протолкнуть более года, наконец воплотилось в жизнь всего за неделю после единственного авторитетного запроса от управления безопасностью.
Пример случая (2)
Этот пример относится к распространенному недостатку дизайна безопасности. Недостаток заключался в том, что важные секретные ключи были жестко запрограммированы в исходном коде, а не загружались программным приложением из внешнего файла (или секретного анклава). Это привело к необходимости выпускать новую версию программного обеспечения (исходного кода) каждый раз, когда необходимо было обновить ключ, и, что еще хуже, один и тот же ключ использовался везде, где запускалось программное обеспечение. Поскольку программное обеспечение было развернуто для различных клиентов, у всех у них были одни и те же ключи в их ИТ-инфраструктуре. Это повлияло не только на безопасность и выпуск негатива, но и на поддержку клиентов. Поскольку использовались одни и те же доверенные отпечатки ключей, доступ к программному обеспечению всегда был проблематичным, поскольку ключи нельзя было передать клиенту — тогда у клиента был бы ключ, который также мог получить доступ к устройствам других клиентов.
Склеивание ключевых материалов с исходными кодами программного обеспечения плохо как с точки зрения влияния на процесс выпуска, так и с точки зрения аспектов безопасности. Опять же, подход, основанный на безопасности, обеспечил бы надлежащую архитектуру, изначально поддерживающую хороший процесс выпуска . Обеспечение того, чтобы конфигурация, ключевой материал и исходный код были разделены, является одной из основных передовых практик при создании программного обеспечения. В принципе, это не что иное, как разделение интересов, хранение вещей, которые принадлежат друг другу, в одном месте. Это здравый смысл. Лучшие практики безопасности полностью соответствуют этому.
В приведенном выше примере правильно выполненная мера безопасности привела к улучшенному решению с повышенным уровнем безопасности, а также к улучшенному процессу выпуска.
Заключительные замечания
Мы должны помнить, что «сложность — враг безопасности», как неоднократно подчеркивал известный авторитет в области кибербезопасности Стив Гибсон, и что порядок и структура являются ключом к продуктивной разработке программного обеспечения (по очевидным причинам). Следует ожидать, что хорошая архитектура по своей сути приведет к безопасности по дизайну, и наоборот, можно ожидать, что решение с учетом безопасности по дизайну будет лежать в основе хорошей программной архитектуры в целом.
Говорят, что кибербезопасность — это процесс, а не продукт. Кстати, разработка программного обеспечения — это тоже процесс. Однако есть разница. Кибербезопасность — это более или менее нисходящий подход, в то время как классическая разработка программного обеспечения, как правило, восходит снизу — по крайней мере, таков мой опыт. Может быть, компетентный орган власти является преимуществом подхода к кибербезопасности в некоторых случаях по сравнению с (гибкой) разработкой программного обеспечения? Факт таков: практика кибербезопасности — это профессионализм, и это может быть самой сильной стороной программного обеспечения.
По мере роста ИТ-решений паутины вы можете подумать о том, чтобы сделать управление безопасностью популярным.