Megosztás a következőn keresztül:

Javaslatok a biztonsági incidensek kezelésére

A Well-Architected Security ellenőrzőlista javaslatára vonatkozik Power Platform :

SE:11 Hatékony incidenskezelési eljárásokat határozhat meg és tesztelhet, amelyek az incidensek széles skáláját lefedik, a lokalizált problémáktól a vészhelyreállításig. Egyértelműen határozza meg, hogy melyik csapat vagy egyén futtatja az eljárást.

Ez az útmutató a számítási feladatok biztonsági incidensekre adott válaszának megvalósítására vonatkozó javaslatokat ismerteti. Ha egy rendszer biztonsági sérülése van, a szisztematikus incidenskezelési megközelítés segít csökkenteni a biztonsági incidensek azonosításához, kezeléséhez és mérsékléséhez szükséges időt. Ezek az incidensek veszélyeztethetik a szoftverrendszerek és adatok bizalmasságát, integritását és rendelkezésre állását.

A legtöbb vállalat rendelkezik központi biztonsági üzemeltetési csapattal (más néven Security Operations Center [SOC] vagy SecOps). A biztonsági üzemeltetési csapat feladata a potenciális támadások gyors észlelése, rangsorolása és osztályozása. A csapat a biztonsággal kapcsolatos telemetriai adatokat is figyeli, és kivizsgálja a biztonsági réseket.

Konceptuális művészet, amely együttműködési megközelítést mutat be a potenciális és a realizált kockázatok csökkentése érdekében.

Ugyanakkor a számítási feladatok védelme is felelősséggel tartozik. Fontos, hogy a kommunikációs, vizsgálati és keresési tevékenységek a számítási feladatok csapata és a SecOps csapata közötti együttműködés legyen.

Ez az útmutató javaslatokat tartalmaz Önnek és a számítási feladatok csapatának a támadások gyors észleléséhez, osztályozásához és kivizsgálásához.

Meghatározások

Kifejezés Definíció
Riasztás Egy incidensről szóló értesítés.
Riasztási hűség A riasztást meghatározó adatok pontossága. A nagy pontosságú riasztások tartalmazzák az azonnali műveletek végrehajtásához szükséges biztonsági környezetet. Az alacsony hűségű riasztások nem tartalmaznak információt, vagy zajt tartalmaznak.
Vakriasztás Riasztás, amely nem történt meg eseményt jelez.
Incident A rendszerhez való jogosulatlan hozzáférést jelző esemény.
Incidensekre adott válasz Olyan folyamat, amely észleli, reagál és csökkenti az incidenshez kapcsolódó kockázatokat.
Osztályozás Incidenskezelési művelet, amely elemzi a biztonsági problémákat, és rangsorolja azok enyhítését.

Kulcsfontosságú tervezési stratégiák

Ön és csapata incidenskezelési műveleteket hajt végre, ha egy jel vagy riasztás potenciális biztonsági incidenst jelez. A nagy pontosságú riasztások bőséges biztonsági környezetet tartalmaznak, amely megkönnyíti az elemzők számára a döntések meghozatalát. A nagy pontosságú riasztások alacsony számú téves riasztást eredményeznek. Ez az útmutató feltételezi, hogy a riasztási rendszer szűri az alacsony pontosságú jeleket, és a valós incidensre utaló nagy pontosságú riasztásokra összpontosít.

Incidensértesítés hozzárendelése

A biztonsági riasztásoknak el kell érniük a csapat és a szervezet megfelelő tagjait. Hozzon létre egy kijelölt kapcsolattartót a számítási feladatok csapatában az incidensértesítések fogadásához. Ezeknek az értesítéseknek a lehető legtöbb információt kell tartalmazniuk a feltört erőforrásról és a rendszerről. A riasztásnak tartalmaznia kell a következő lépéseket, hogy a csapat felgyorsíthassa a műveleteket.

Javasoljuk, hogy naplózza és kezelje az incidensértesítéseket és műveleteket olyan speciális eszközökkel, amelyek naplózási naplót tartanak. A szabványos eszközök használatával megőrizheti azokat a bizonyítékokat, amelyekre szükség lehet a lehetséges jogi vizsgálatokhoz. Keressen lehetőségeket olyan automatizálás megvalósítására, amely az elszámoltatható felek felelőssége alapján értesítéseket küldhet. Tartson egyértelmű kommunikációs és jelentési láncot egy incidens során.

Használja ki a szervezet által biztosított biztonsági információs eseménykezelési (SIEM) és biztonsági vezénylési automatizált válasz (SOAR) megoldásokat. Alternatív megoldásként beszerezhet incidenskezelő eszközöket, és arra ösztönözheti a szervezetet, hogy szabványosítsa azokat az összes számítási feladattal foglalkozó csapat számára.

Vizsgálat osztályozási csapattal

Az incidensről értesítést kapó csapattag felelős egy olyan osztályozási folyamat beállításáért, amely a rendelkezésre álló adatok alapján a megfelelő személyeket vonja be. A triage csapatnak, amelyet gyakran hídcsapatnak neveznek, meg kell állapodnia a kommunikáció módjáról és folyamatáról. Ehhez az incidenshez aszinkron megbeszélésekre vagy hídhívásokra van szükség? Hogyan kell a csapatnak nyomon követnie és kommunikálnia a vizsgálatok előrehaladását? Hol férhet hozzá a csapat az incidenseszközökhöz?

Az incidensekre való reagálás kulcsfontosságú oka annak, hogy a dokumentáció naprakészen maradjon, például a rendszer architekturális elrendezése, az összetevők szintjén lévő információk, az adatvédelmi vagy biztonsági besorolás, a tulajdonosok és a legfontosabb kapcsolattartási pontok. Ha az információk pontatlanok vagy elavultak, a hídcsapat értékes időt pazarol arra, hogy megértse, hogyan működik a rendszer, ki a felelős az egyes területekért, és milyen hatása lehet az eseménynek.

További vizsgálatokhoz vonja be a megfelelő embereket. Tartalmazhat incidenskezelőt, biztonsági tisztviselőt vagy számítási feladat-központú érdeklődőket. Az osztályozás fókuszálása érdekében zárja ki azokat az embereket, akik kívül esnek a probléma hatókörén. Néha külön csapatok vizsgálják az esetet. Lehet, hogy van egy csapat, amely kezdetben kivizsgálja a problémát, és megpróbálja enyhíteni az incidenst, és egy másik speciális csapat, amely kriminalisztikát végezhet egy mélyreható vizsgálat érdekében, hogy megállapítsa a széles körű problémákat. A számítási feladat környezetét karanténba helyezheti, hogy a kriminalisztikai csapat elvégezhesse a vizsgálatokat. Bizonyos esetekben ugyanaz a csapat kezelheti a teljes nyomozást.

A kezdeti szakaszban a triázs csapat felelős a potenciális vektor meghatározásáért és annak a rendszer titkosságára, integritására és rendelkezésre állására gyakorolt hatásáért (más néven CIA).

A CIA kategóriáin belül rendeljen hozzá egy kezdeti súlyossági szintet, amely jelzi a kár mélységét és a helyreállítás sürgősségét. Ez a szint várhatóan idővel változik, ahogy több információt fedeznek fel az osztályozás szintjein.

A felfedezési fázisban fontos meghatározni az azonnali cselekvési irányt és a kommunikációs terveket. Változott-e a rendszer működési állapota? Hogyan lehet a támadást megfékezni a további kizsákmányolás megállítása érdekében? A csapatnak belső vagy külső kommunikációt kell küldenie, például felelősségteljes közzétételt? Vegye figyelembe az észlelési és válaszidőt. Előfordulhat, hogy jogilag köteles bizonyos típusú jogsértéseket jelenteni a szabályozó hatóságnak egy meghatározott időn belül, amely gyakran órák vagy napok.

Ha úgy dönt, hogy leállítja a rendszert, a következő lépések a számítási feladat vészhelyreállítási (DR) folyamatához vezetnek.

Ha nem állítja le a rendszert, határozza meg, hogyan orvosolhatja az incidenst anélkül, hogy ez hatással lenne a rendszer működésére.

Helyreállítás incidensből

Kezelje a biztonsági incidenseket katasztrófaként. Ha a szervizelés teljes helyreállítást igényel, biztonsági szempontból használjon megfelelő vészhelyreállítási mechanizmusokat. A helyreállítási folyamatnak meg kell akadályoznia a megismétlődés esélyét. Ellenkező esetben a sérült biztonsági másolatból történő helyreállítás újra bevezeti a problémát. Az azonos biztonsági résszel rendelkező rendszer újbóli telepítése ugyanahhoz az incidenshez vezet. Ellenőrizze a feladatátvételi és feladat-visszavételi lépéseket és folyamatokat.

Ha a rendszer továbbra is működik, mérje fel a rendszer futó részeire gyakorolt hatást. Folytassa a rendszer figyelését annak biztosítása érdekében, hogy a többi megbízhatósági és teljesítménycél teljesüljön vagy megfelelő romlási folyamatok végrehajtásával módosuljon. Ne veszélyeztesse az adatvédelmet a kockázatcsökkentés miatt.

A diagnózis egy interaktív folyamat, amíg a vektort, valamint a lehetséges javítást és tartalékot meg nem azonosítják. A diagnózis után a csapat a szervizelésen dolgozik, amely elfogadható időn belül azonosítja és alkalmazza a szükséges javítást.

A helyreállítási metrikák azt mérik, hogy mennyi ideig tart a probléma megoldása. Leállás esetén sürgős lehet a szervizelési idők tekintetében. A rendszer stabilizálásához időbe telik a javítások, javítások és tesztek alkalmazása, valamint a frissítések telepítése. Határozza meg az elszigetelési stratégiákat a további károk és az incidens terjedésének megelőzése érdekében. Dolgozzon ki felszámolási eljárásokat a környezetből származó fenyegetés teljes eltávolítására.

Kompromisszum: Kompromisszum van a megbízhatósági célok és a szervizelési idők között. Incidens során valószínű, hogy nem felel meg más nem funkcionális vagy funkcionális követelményeknek. Előfordulhat például, hogy le kell tiltania a rendszer egyes részeit az incidens kivizsgálása közben, vagy akár a teljes rendszert offline állapotba kell helyeznie, amíg meg nem határozza az incidens hatókörét. Az üzleti döntéshozóknak kifejezetten el kell dönteniük, hogy melyek az elfogadható célok az incidens során. Egyértelműen határozza meg a döntésért felelős személyt.

Tanuljon egy incidensből

Az incidens hiányosságokat vagy sebezhető pontokat tár fel a tervezésben vagy a megvalósításban. Ez egy olyan fejlesztési lehetőség, amelyet a műszaki tervezési szempontok, az automatizálás, a tesztelést magában foglaló termékfejlesztési folyamatok és az incidenskezelési folyamat hatékonyságának leckéi vezérelnek. Részletes incidensnyilvántartást vezet, beleértve a megtett intézkedéseket, az ütemterveket és a megállapításokat.

Erősen javasoljuk, hogy végezzen strukturált incidens utáni felülvizsgálatokat, például kiváltó okok elemzését és visszamenőleges vizsgálatait. Kövesse nyomon és rangsorolja a felülvizsgálatok eredményét, és fontolja meg a tanultak felhasználását a jövőbeli számítási feladatok tervezésében.

A fejlesztési terveknek tartalmazniuk kell a biztonsági próbák és tesztelések frissítéseit, például az üzletmenet-folytonossági és vészhelyreállítási (BCDR) próbákat. Biztonsági biztonsági rés használata forgatókönyvként a BCDR-próbák végrehajtásához. A drillek ellenőrizhetik a dokumentált folyamatok működését. Nem lehet több incidenskezelési forgatókönyv. Használjon egyetlen forrást, amelyet az incidens mérete és a hatás elterjedtsége vagy lokalizáltsága alapján módosíthat. A gyakorlatok hipotetikus helyzeteken alapulnak. Végezzen gyakorlatokat alacsony kockázatú környezetben, és vegye be a tanulási fázist a gyakorlatokba.

Végezzen incidens utáni felülvizsgálatokat vagy post mortemeket, hogy azonosítsa a válaszadási folyamat gyengeségeit és a javítandó területeket. Az incidensből levont tanulságok alapján frissítse az incidenskezelési tervet (IRP) és a biztonsági vezérlőket.

Küldje el a szükséges kommunikációt

Kommunikációs terv végrehajtása a felhasználók értesítésére a fennakadásról, valamint a belső érdekelt felek tájékoztatása a szervizelésről és a fejlesztésekről. A szervezet más tagjait értesíteni kell a számítási feladat biztonsági alapkonfigurációjának változásairól a jövőbeli incidensek megelőzése érdekében.

Incidensjelentések készítése belső használatra, és szükség esetén szabályozási megfelelőségi vagy jogi célokra. Fogadjon el egy szabványos formátumú jelentést (meghatározott szakaszokkal rendelkező dokumentumsablont) is, amelyet az SOC-csapat minden incidenshez használ. A vizsgálat lezárása előtt győződjön meg arról, hogy minden incidenshez tartozik egy jelentés.

Power Platform Megkönnyítése

A következő szakaszok a biztonsági incidensekre való reagálási eljárások részeként alkalmazható mechanizmusokat ismertetik.

Microsoft Sentinel

A Microsoft Sentinel megoldása Microsoft Power Platform lehetővé teszi az ügyfelek számára a különböző gyanús tevékenységek észlelését, beleértve a következőket:

  • Power Apps Végrehajtás jogosulatlan földrajzi területekről
  • Gyanús adatmegsemmisítés Power Apps
  • Tömeges törlés Power Apps
  • Adathalász támadások Power Apps
  • Power Automate Áramlási tevékenység távozó alkalmazottak szerint
  • Microsoft Power Platform Környezethez hozzáadott összekötők
  • Adatveszteség-megelőzési szabályzatok frissítése vagy eltávolítása Microsoft Power Platform

További információ: Microsoft Sentinel-megoldás Microsoft Power Platform áttekintés.

Microsoft Purview tevékenységnaplózás

Power Apps, Power Automate, Az összekötők, az adatveszteség-megelőzés és a Power Platform felügyeleti tevékenységek naplózása nyomon követhető és megtekinthető a Microsoft Purview megfelelőségi portál.

További információkért lásd:

Ügyfélszéf

A Microsoft munkatársai (beleértve az alfeldolgozókat is) által végzett legtöbb művelethez, támogatáshoz és hibaelhárításhoz nincs szükség az ügyféladatokhoz való hozzáférésre. Az Ügyfélszéf segítségével Power Platform a Microsoft felületet biztosít az ügyfelek számára az adathozzáférési kérelmek áttekintéséhez és jóváhagyásához (vagy elutasításához) azokban a ritka esetekben, amikor adathozzáférésre van szükség az ügyféladatokhoz. Olyan esetekben használatos, amikor egy Microsoft-mérnöknek hozzá kell férni az ügyféladatokhoz, akár ügyfél által indított támogatási jegy kapcsán, akár a Microsoft által azonosított probléma megoldása során. További tájékoztatás: Biztonságos hozzáférés az ügyféladatokhoz Power Platform az Ügyfélszéf és a Dynamics 365 használatával.

Biztonsági frissítések

A szolgáltatási csapatok rendszeresen elvégzik az alábbiakat a rendszer biztonsága érdekében:

  • A szolgáltatás vizsgálata a lehetséges biztonsági rések azonosítása érdekében.
  • A szolgáltatás értékelése a kulcsfontosságú biztonsági vezérlők hatékony működésének biztosítása érdekében.
  • A szolgáltatás értékelése a Microsoft Security Response Center (MSRC) által azonosított biztonsági réseknek való kitettség meghatározása érdekében, amely rendszeresen figyeli a külső biztonsági résekkel foglalkozó webhelyeket.

Ezek a csapatok azonosítanak és nyomon követnek minden azonosított problémát is, és szükség esetén gyorsan cselekszenek a kockázatok csökkentése érdekében.

Hogyan tájékozódhatok a biztonsági frissítésekről?

Mivel a szolgáltatási csapatok arra törekszenek, hogy a kockázatcsökkentést olyan módon alkalmazzák, amely nem igényel szolgáltatásleállást, a rendszergazdák általában nem látják az Üzenetközpont értesítéseit a biztonsági frissítésekről. Ha egy biztonsági frissítés hatással van a szolgáltatásra, akkor az tervezett karbantartásnak minősül, és a rendszer a becsült hatásidőtartammal és a munka bekövetkezésének időpontjával együtt lesz közzétéve.

További információ a biztonságról: Microsoft Adatvédelmi központ.

A karbantartási időszak kezelése

A Microsoft rendszeresen végez frissítéseket és karbantartásokat a biztonság, a teljesítmény és a rendelkezésre állás biztosítása érdekében, valamint új funkciók és funkciók biztosítása érdekében. Ez a frissítési folyamat heti szinten biztosít biztonsági és kisebb szolgáltatásfejlesztéseket, a frissítéseket régiónként, a biztonságos telepítés ütemezésének megfelelően, Állomásokba szervezetten bevezetve. További információ a környezetek alapértelmezett karbantartási időszakáról: Házirendek és kommunikáció szolgáltatási incidensekhez. Lásd még: A karbantartási időszak kezelése.

Győződjön meg arról, hogy az Azure-regisztrációs portál tartalmazza a rendszergazda kapcsolattartási adatait, így a biztonsági műveletek közvetlenül egy belső folyamaton keresztül értesíthetők. További információ: Értesítési beállítások frissítése.

Szervezeti összehangolás

Az Azure-hoz készült felhőadaptálási keretrendszer útmutatást nyújt az incidenskezelési tervezéshez és a biztonsági műveletekhez. További információ: Biztonsági műveletek.

Biztonsági ellenőrzőlista

Tekintse meg a teljes javaslatot.

Biztonsági ellenőrzőlista