За да могат специалистите по киберсигурност да получат знанията, от които се нуждаят, за да осуетят хакерите, постоянно насочени към тяхната облачна инфраструктура и приложения, те трябва да мислят като генерал Джордж С. Патън (или по-скоро като Джордж С. Скот, актьорът, спечелил Оскар за най-добър актьор за образа му на генерала във филма от 1970 г Патън).
В една ранна сцена камерата се фокусира върху книга, която Патън чете от германския генерал Ервин Ромел. Въпросът е да се покаже как Патън не разчита единствено на военното разузнаване, за да планира следващата битка. Той е проактивен в научаването на колкото може повече за това как мисли и действа неговият противник. Следващата сцена изобразява войските на Патън, които започват опустошителна атака срещу немски танкове и пехота. Поглеждайки през бинокъла си, Патън се усмихва и вика „Ромел, ти великолепен (руга), прочетох книгата ти!“
Също така и лидерите в бизнеса и сигурността трябва да бъдат проактивни в натрупването на възможно най-много знания за мотивацията и тактиките на хакерите. Не разчитайте само на това, което вашите решения за сигурност ви казват, защото това само ще ви даде фалшиво усещане за сигурност. Всеки ден хакерите заобикалят периметрите на сигурността, пресичат произволни граници и избягват решенията за сигурност, за да получат в крайна сметка данните, които искат, без да бъдат разкрити.
В това видео, Джош Стелаглавен архитект в Сник и основател главен изпълнителен директор на фугаSaaS компания за сигурност в облака, разработчици, обяснява защо ръководителите трябва да помолят своите екипи по сигурността да им предоставят знания за работната облачна среда и ефективно да предадат това на други ръководители, за да оправдаят инвестициите в сигурността между всички екипи.
Вашите противници вероятно няма да напишат книги за техните методологии, които да изучавате. И така, ето девет въпроса, които всички висши ръководители (CISO, CIO, CEO) трябва да зададат относно тяхната сигурност в облака и на които техните екипи за сигурност в облака трябва да знаят отговорите по всяко време.
Доколко нашата облачна среда не отговаря на изискванията?
Нито една корпоративна организация, работеща в облака, няма среда, която е 100% в съответствие с регулаторните политики и политиките за сигурност. Но тези, които правят облачна сигурност правилно, знаят точно къде е тяхната среда и не е в съответствие. Те гарантират, че изключенията са точно това – изключения от правилото – и имат приоритетен план за привеждане на всичко в съответствие.
Трябва да знаете по всяко време къде се намирате по отношение на сигурността и съответствието на вашата облачна среда. Вашият екип по сигурността трябва редовно да преглежда вътрешните корпоративни политики за сигурност, за да се увери, че отговарят адекватно на вашите случаи на използване и възникващи вектори на атака. Разберете процеса, който вашият екип използва за откриване на несъответстваща облачна инфраструктура, процеса на коригиране, който имат, и времето, необходимо за привеждане на средата в съответствие.
Колко уязвимости идентифицирахме и елиминирахме?
Вашата позиция за сигурност в облака не е статична и трябва да се подобри с времето, тъй като екипът ви става по-добър в идентифицирането и отстраняването на проблеми. Трябва да имате информация за това колко уязвимости при неправилна конфигурация съществуват във вашата среда и колко се отстраняват на ден.
Тъй като това усилие обикновено включва много ръчна работа, включваща инструменти за наблюдение и системи за продажба на билети, ще искате да използвате автоматизацията, за да помогнете на екипа си да се справи с мащаба на сложността, включен в съвременните корпоративни облачни среди. Работете с професионалисти по сигурността в облака с опит в домейна, за да разберете как се случват съвременни големи пробиви в облака и използвайте това знание, за да създадете политика като код които могат да се използват за автоматична проверка дали същите тези условия съществуват в облачната инфраструктура на организацията. Политиката като код е предназначена да проверява друг код и работещи среди за нежелани условия. Той дава възможност на всички заинтересовани страни в облака да работят сигурно без неясноти или разногласия относно правилата и как да ги прилагат и в двата края на жизнения цикъл на разработката на софтуер.
Колко уязвимости предотвратихме разгръщането им?
Познаването кои уязвимости открива и отстранява вашият екип по сигурността във вашата облачна среда е само една част от цялостния пъзел за сигурност. Също така искате да знаете какви проактивни стъпки предприема екипът по сигурността, за да намали честотата на внедряването на неправилни конфигурации. Неуспехът да се „премести наляво“ при сигурността в облака гарантира, че ще има непрекъснат поток от уязвимости в облака във вашата среда – и екип по сигурността, който играе безкрайна игра на удари.
Вашият екип има ли сигурност, вградена в тръбопроводи за непрекъсната интеграция и непрекъсната доставка (CI/CD)? Вашият екип проверява ли инфраструктурата като код (средство за програмно изграждане и разгръщане на облачна инфраструктура), за да намери и коригира неправилни конфигурации преди внедряването, когато това е по-бързо, по-лесно и по-безопасно? Ако отговорите тук са „не“, може да се окаже, че инфраструктурата като код и CI/CD конвейери не са приети. Но ако те се използват, трябва поне да има план за вграждане на сигурност в тези процеси.
Осигуряваме ли контролната равнина на облачния API?
Всички пробиви в облака следват същия модел: компрометиране на контролната равнина. Интерфейсите за програмиране на приложения (API) са основният двигател на изчисленията в облак; мислете за тях като за „софтуерни посредници“, които позволяват на различни приложения да взаимодействат помежду си. Равнината за управление на API е колекцията от API, използвани за конфигуриране и управление на облака.
Хакерите търсят неправилни конфигурации. За съжаление, индустрията за сигурност остава една крачка зад хакерите, защото много решения на доставчици не защитават своите клиенти срещу атаки, насочени към равнината за управление на облака. Честно казано, повечето от тях се фокусират върху квадратчетата за отметка, които карат висшите ръководители и екипите по сигурността да се чувстват по-добре – докато не бъдат хакнати. Театърът за сигурност е твърде разпространен в нашия бизнес.
Оценяването на риска от радиус на взрив от всяко потенциално събитие от проникване поради неправилна конфигурация, уязвимости на приложения, API ключове в изходния код и т.н., изисква опит в архитектурата за сигурност в облака, за да се идентифицират и избегнат недостатъците на дизайна, които нападателите използват всеки ден. Сигурността в облака е свързана със знания и пробиви се случват, когато защитниците не разполагат с пълно познаване на тяхната среда и не успяват да откажат на атакуващите да открият това знание.
Колко съпротивление върху производителността създава сигурността?
Облакът е свързан със скоростта на иновациите, а сигурността е фактор номер едно, ограничаващ скоростта за това колко бързи могат да се движат екипите и колко успешна може да бъде дигиталната трансформация. Изчакват ли разработчиците на приложения за инфраструктурата, която трябва да разгърнат? Екипите на DevOps чакат ли сигурността, за да прегледа и одобри тяхната инфраструктура? Вашите облачни инженери инвестират ли твърде много часове в отнемащи време ръчни задачи за сигурност и съответствие, когато биха могли да създадат повече стойност за вашата компания и клиенти?
Редовното измерване на производителността на разработчиците и DevOps ще помогне за идентифициране на закъснения поради недостатъчни процеси за сигурност, които пречат на производителността и морала.
Как изразяваме политиките за сигурност?
Има два отговора на този въпрос: Вашите политики за сигурност са написани на човешки език и се преглеждат от хора, или използвате политиката като код. Ако отговорът е първият, вашите облачни среди не могат да бъдат достатъчно защитени. Отнема време за ръчен преглед на правилата и прилагането им във вашата среда в момент, когато пробивите в облака се изпълняват минути. А рисковете от човешка грешка и различия в тълкуването винаги са налице.
С политиката като код, машините ще интерпретират точно една политика по един и същи начин всеки път в реално време, което означава, че можете непрекъснато да оценявате много повече облачна инфраструктура, отколкото която и да е армия от хора може да се надява да направи. Ако прилагането на политиката за сигурност трябва да се промени от едно внедряване в друго, можете да изразите тези изключения като код, така че всичко да е добре документирано. Когато внедрите автоматизация на сигурността, използвайки политика като код, проблемите могат да бъдат открити и отстранени при разработката или внедряването, преди да се достигне до производство.
Колко бързо можем да реагираме на събития с нулев ден?
Недостатъкът на Log4j по-рано тази година изпрати екипи по сигурността навсякъде да се борят да отговорят. Тези видове събития от „нулев ден“ изискват от екипите бързо и точно да преценят къде съществуват уязвимости и тяхната сериозност, за да дадат приоритет на вашата реакция и усилия за отстраняване. Реакцията на подобни експлойти на приложения нулев ден изисква екипите да навлизат по-дълбоко, отколкото обикновено правят, тъй като уязвимостите на приложенията често се използват за проникване в средата на облачната инфраструктура – и в крайна сметка компрометират равнината на управление на облака.
Екипите трябва не само да могат бързо да идентифицират уязвимостите в приложенията, но и да оценят потенциалния радиус на взрив, който представлява всеки екземпляр на уязвимостта, за да определят сериозността и съответно да приоритизират отстраняването.
Всички отбори имат ли това, от което се нуждаят, за да успеят?
В съвременната корпоративна сигурност няма силози. Сигурността изисква интегриран подход, който обхваща екипи и разходни центрове, което изисква изпълнително лидерство и спонсорство, за да се постигне правилно. Например, подходът с изместване наляво към сигурността изисква от разработчиците и DevOps да поемат известна отговорност за намиране и отстраняване на проблеми по-рано в жизнения цикъл на разработка на софтуер. Но ако инвестициите в сигурността не отразяват тези нови приоритети, ще има търкания, които поставят усилията в опасност.
Успехът в сигурността зависи от спонсорството на изпълнителната власт с адекватни инвестиции както на бюджет, така и на време.
Как ще изглежда провалът?
Отвъд CISO виждам твърде малко ръководители, които наистина си задават този въпрос. Не е трудно да си представим – помислете за пробива в облака, който удари Imperva, самата голяма компания за продукти за сигурност, което в крайна сметка доведе до оттеглянето на главния изпълнителен директор. След това има пробив в Capital One, който все още е един от най-големите, които някога са засягали голяма финансова институция. И нарушението на Twitch по-рано тази година, което засегна не само Twitch, но и родителския Amazon. За разлика от поражението на генерал Патън от генерал Ромел, няма да има победи за бизнес лидерите, а само постоянен стремеж за предотвратяване на провал.
Сигурността в облака е вечно начинание, като присъединяването към фитнес зала и стриктното използване на това членство, за да влезете и останете във форма. Трябва да приложите политика, изискваща последователно отчитане за облачната сигурност на вашата организация. Не искате да се борите с въпроси за това какво се прави за идентифициране и отстраняване на уязвимостите, колко са елиминирани миналата седмица или миналия месец и къде може да сте изложени на нова уязвимост, която прави заглавията на новините – искате отговори.
Джош Стела е главен архитект в Snyk и технически орган по сигурността в облака. Джош носи 25 години опит в областта на ИТ и сигурността като главен изпълнителен директор в фуга, основен архитект на решения в Amazon Web Services и съветник на американската разузнавателна общност. Личната мисия на Джош е да помогне на организациите да разберат как облачната конфигурация е новата повърхност за атака и как компаниите трябва да преминат от защитна към превантивна позиция, за да осигурят своята облачна инфраструктура. Той написа първата книга за „Неизменна инфраструктура“ (публикувана от O’Reilly), притежава множество патенти за технологии за облачна сигурност и е домакин на образователна поредица от майсторски класове по облачна сигурност. Свържете се с Джош LinkedInи за повече информация относно Fugue, SaaS компания за сигурност в облака, която е първа за разработчици, посетете www.fugue.co, GitHub, LinkedIn, и Twitter.
—
New Tech Forum предоставя място за изследване и обсъждане на нововъзникващите корпоративни технологии в безпрецедентна дълбочина и ширина. Изборът е субективен, базиран на нашия избор на технологиите, които смятаме за важни и представляващи най-голям интерес за читателите на InfoWorld. InfoWorld не приема маркетингови обезпечения за публикуване и си запазва правото да редактира цялото предоставено съдържание. Изпращайте всички запитвания на newtechforum@infoworld.com.
Авторско право © 2022 IDG Communications, Inc.
https://www.infoworld.com/article/3660058/9-questions-you-should-ask-about-your-cloud-security.html#tk.rss_all
