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


Javaslatok a biztonsági incidensekre való reagáláshoz

A jól felépített biztonsági ellenőrzőlistára vonatkozó javaslatra Power Platform vonatkozik:

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ést szenved, a szisztematikus incidenskezelési megközelítés segít csökkenteni a biztonsági incidensek azonosításához, kezeléséhez és enyhítéséhez szükséges időt. Ezek az incidensek veszélyeztethetik a szoftverrendszerek és adatok titkosságát, integritását és rendelkezésre állását.

A legtöbb vállalat rendelkezik központi biztonsági műveleti csapattal (más néven Security Operations Center [SOC] vagy SecOps). A biztonsági műveleti 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 incidenseket.

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

Ugyanakkor Ön is felelős a munkaterhelés védelméért. Fontos, hogy minden kommunikációs, vizsgálati és keresési tevékenység a számítási feladatok csapata és a SecOps-csapat közötti együttműködési erőfeszítés legyen.

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

Meghatározások

Kifejezés Definíció
Riasztás Egy incidenssel kapcsolatos információkat tartalmazó értesítés.
Riasztási hűség A riasztást meghatározó adatok pontossága. A kiváló minőségű riasztások tartalmazzák az azonnali műveletekhez szükséges biztonsági környezetet. A hifi riasztások nem tartalmaznak információt, vagy zajt tartalmaznak.
Vakriasztás Egy riasztás, amely olyan incidenst jelez, amely nem történt meg.
Ügy Olyan esemény, amely a rendszerhez való jogosulatlan hozzáférést jelzi.
Incidensre adott válasz Olyan folyamat, amely észleli, reagál és csökkenti az incidensekhez kapcsolódó kockázatokat.
Osztályozás Egy incidensválasz-művelet, amely elemzi a biztonsági problémákat, és rangsorolja azok megoldását.

Fő 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 kiváló minőségű riasztások bőséges biztonsági környezetet tartalmaznak, amely megkönnyíti az elemzők számára a döntéshozatalt. A kiváló minőségű riasztások alacsony számú téves riasztást eredményeznek. Ez az útmutató feltételezi, hogy egy riasztási rendszer szűri az alacsony hűségű jeleket, és a nagy pontosságú riasztásokra összpontosít, amelyek valós incidenst jelezhetnek.

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

A biztonsági riasztásoknak el kell érniük a csapat és a szervezet megfelelő személyeit. 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 auditnaplót vezetnek. A szokásos eszközök használatával megőrizheti azokat a bizonyítékokat, amelyekre szükség lehet a lehetséges jogi vizsgálatokhoz. Keresse meg az automatizálás megvalósításának lehetőségeit, amelyek értesítéseket küldhetnek az elszámoltatható felek felelőssége alapján. Tartson egyértelmű kommunikációs és jelentési láncot az incidensek során.

Használja ki a szervezet által biztosított biztonsági információs eseménykezelés (SIEM) megoldások és a biztonsági vezénylési automatikus válasz (SOAR) megoldások előnyeit. Másik lehetőségként beszerezheti az incidenskezelési eszközöket, és arra ösztönözheti a szervezetet, hogy szabványosítsa őket az összes számítási feladattal foglalkozó csapat számára.

Kivizsgálás osztályozási csapattal

Az incidensértesítéseket kapó csapattag felelős egy osztályozási folyamat beállításáért, amely a rendelkezésre álló adatok alapján bevonja a megfelelő személyeket. A triázs csapatnak, amelyet gyakran bridzscsapatnak neveznek , meg kell állapodnia a kommunikáció módjáról és folyamatáról. Szükség van erre az incidensre aszinkron megbeszélésekre vagy hídhívásokra? Hogyan kell a csapatnak nyomon követnie és kommunikálnia a vizsgálatok előrehaladását? Hol férhet hozzá a csapat az incidensek eszközeihez?

Az incidensekre adott válasz kulcsfontosságú ok a dokumentáció naprakészen tartására, például a rendszer architekturális elrendezésére, az összetevők szintjén lévő információkra, az adatvédelmi vagy biztonsági besorolásra, a tulajdonosokra és a legfontosabb kapcsolattartási pontokra. Ha az információk pontatlanok vagy elavultak, a híd csapata értékes időt pazarol arra, hogy megpróbálja megérteni a rendszer működését, ki felelős az egyes területekért, és mi lehet az esemény hatása.

A 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. A triázs fókuszának fenntartá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 eseményt. Lehet, hogy van egy csapat, amely kezdetben kivizsgálja a problémát, és megpróbálja enyhíteni az eseményt, és egy másik speciális csapat, amely kriminalisztikát végezhet egy mély vizsgálathoz a széles körű kérdések megállapítása érdekében. Karanténba helyezheti a számítási feladatok környezetét, hogy a kriminalisztikai csapat elvégezhesse a vizsgálatokat. Bizonyos esetekben ugyanaz a csapat kezelheti a teljes vizsgálatot.

A kezdeti fázisban a triázscsapat felelős a potenciális vektor meghatározásáért és annak a rendszer titkosságára, integritására és elérhetőségére (más néven CIA) gyakorolt hatásáért.

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 idővel várhatóan változni fog, ahogy egyre több információ fedeződik fel az osztályozási szintekben.

A felderítési fázisban fontos meghatározni az azonnali cselekvési irányt és a kommunikációs terveket. Van-e változás a rendszer futási állapotában? Hogyan lehet megfékezni a támadást a további kihasználás megállítása érdekében? A csapatnak belső vagy külső kommunikációt kell küldenie, például felelős 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 befolyásolná a rendszer működését.

Helyreállítás incidens után

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ő DR-mechanizmusokat. A helyreállítási folyamatnak meg kell akadályoznia az ismétlődés esélyét. Ellenkező esetben a sérült biztonsági mentésből való helyreállítás újra bevezeti a problémát. Az azonos biztonsági résű rendszer újbóli üzembe helyezé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, értékelje a rendszer futó részeire gyakorolt hatást. Továbbra is figyelemmel kíséri a rendszert annak biztosítása érdekében, hogy más megbízhatósági és teljesítménycélok teljesüljenek, vagy megfelelő romlási folyamatok végrehajtásával korrigálják azokat. Ne veszélyeztesse az adatvédelmet a kockázatcsökkentés miatt.

A diagnózis interaktív folyamat, amíg a vektort, valamint a lehetséges javítást és tartalékot 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 egy probléma megoldása. Leállás esetén sürgős lehet a szervizelési idő. 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. Felszámolási eljárások kidolgozása a fenyegetés teljes eltávolítása érdekében.

Kompromisszum: A megbízhatósági célok és a szervizelési idők között kompromisszum van. Egy 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 azt a személyt, aki felelős a döntésért.

Tanuljon egy incidensből

Az incidensek feltárják a tervezés vagy megvalósítás hiányosságait vagy sebezhető pontjait. Ez egy 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ága terén szerzett tanulságok vezérelnek. Részletes incidensnyilvántartást vezethet, beleértve a megtett lépéseket, az ütemterveket és az eredményeket.

Javasoljuk, hogy végezzen strukturált, incidens utáni felülvizsgálatokat, például a kiváltó okok elemzését és a visszatekintéseket. 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. Használja a biztonsági sérülést a BCDR-részletezés végrehajtásának forgatókönyveként. A drillek ellenőrizhetik a dokumentált folyamatok működését. Nem lehet több incidensválasz-forgatókönyv. Használjon egyetlen forrást, amelyet az incidens mérete, valamint a hatás széles körű vagy lokalizált állapota alapján módosíthat. A drillek hipotetikus helyzeteken alapulnak. Végezzen gyakorlatokat alacsony kockázatú környezetben, és foglalja bele a tanulási fázist a drillekbe.

Incidens utáni felülvizsgálatok vagy post mortem vizsgálatok elvégzése a reagálási folyamat gyengeségeinek és a javításra szoruló területeknek az azonosítása érdekében. Az incidensből levont tanulságok alapján frissítse az incidensválasz-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, amely értesíti a felhasználókat a zavarról, és tájékoztatja a belső érdekelt feleket a szervizelésről és a fejlesztésekről. A szervezet többi tagját é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 létrehozása belső használatra, és szükség esetén szabályozási megfelelőségi vagy jogi célokra. Emellett fogadjon el egy szabványos formátumú jelentést (egy meghatározott szakaszokkal rendelkező dokumentumsablont), 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 azokat a mechanizmusokat ismertetik, amelyeket a biztonsági incidensekre való reagálási eljárások részeként alkalmazhat.

Microsoft Sentinel

A Microsoft Sentinel-megoldás lehetővé teszi az Microsoft Power Platform ü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 helyekről
  • Gyanús adatmegsemmisítés Power Apps
  • Tömeges törlés Power Apps
  • Adathalász támadások Power Apps
  • Power Automate Folyamatok a távozó alkalmazottak tevékenységével
  • Microsoft Power Platform Környezethez hozzáadott összekötők
  • Adatveszteség-megelőzési házirendek Microsoft Power Platform frissítése vagy eltávolítása

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

Microsoft Purview tevékenységnaplózás

Power Apps, Power Automate, Az összekötőket, az adatveszteség-megelőzést és Power Platform a felügyeleti tevékenységek naplózását a Microsoft Purview megfelelőségi portálon követi nyomon és tekinti meg.

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

Ügyfélszéf

A Microsoft személyzete (beleértve az alfeldolgozókat is) által végzett legtöbb művelet, támogatás és hibaelhárítás nem igényel hozzáférést az ügyféladatokhoz. 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) abban a ritka esetben, 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: Ügyféladatok biztonságos elérése az Ügyfélszéf és a Power Platform 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 annak biztosítása érdekében, hogy a kulcsfontosságú biztonsági ellenőrzések hatékonyan működjenek.
  • A szolgáltatás értékelése a külső biztonsági résekkel kapcsolatos tudatossági webhelyeket rendszeresen figyelő Microsoft Security Response Center (MSRC) által azonosított biztonsági réseknek való kitettség meghatározásához.

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 értesülhetek 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ás-állásidőt, a rendszergazdák általában nem látják Üzenetközpont biztonsági frissítésekkel kapcsolatos értesítéseket. Ha egy biztonsági frissítés hatással van a szolgáltatásra, akkor tervezett karbantartásnak minősül, és a becsült hatástartammal, valamint a munka bekövetkezésének ablakával együtt lesz közzétéve.

A biztonsággal kapcsolatos további információkért lásd: 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, valamint az új szolgáltatások é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: Szabályzatok é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álja tartalmazza a rendszergazdai kapcsolattartási adatokat, hogy a biztonsági műveletek közvetlenül egy belső folyamaton keresztül értesülhessenek. További információ: Értesítési beállítások frissítése.

Szervezeti összehangolás

Cloud Adoption Framework Azure-hoz útmutatást nyújt az incidensekre adott válaszok tervezéséhez és a biztonsági műveletekhez. További információ: Biztonsági műveletek.

Kapcsolódó információk

Biztonsági ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.