PWN-ALL · Kiberbiztonság és szoftverfejlesztés

A PWN-ALL négy egymással összefüggő szolgáltatási területet kínál: behatolási tesztelés és támadási szimuláció; incidenskezelés és digitális kriminalisztika; biztonságos Rust- és Python-szoftverfejlesztés; valamint gyártófüggetlen biztonsági tanácsadás. Minden megbízáshoz írásbeli feladatleírás, konkrét teljesítési eredmények és előre egyeztetett átvételi kritériumok tartoznak.

Igen. A PWN-ALL Auditing, Reviewing & Testing Cyber Risks CO. L.L.C. egy 2024-ben alapított, az Egyesült Arab Emírségekbeli Dubajban működő vállalat, amely a dubaji DET 1324553. számú engedély alapján működik. A vállalat D-U-N-S-száma 571235572, NCAGE-kódja pedig 10G8W.

Elsősorban vállalatokkal, kormányzati szervezetekkel és nagy értékű platformokkal dolgozunk együtt világszerte. A megbízásokat joghatóságok között is távolról tudjuk teljesíteni, a kommunikáció pedig több mint 20 nyelven lehetséges; a helyszínhez kapcsolódó jogi, bizonyítékkezelési vagy adatkezelési követelményeket a projekt hatókörének meghatározása során egyeztetjük.

Igen. Az érzékeny adatok megosztása előtt aláírhatunk titoktartási megállapodást (NDA), és használhatjuk a Signal alkalmazást, a PGP-vel titkosított e-mailt vagy az ügyfél által jóváhagyott egyéb kommunikációs csatornát. Az ügyféladatokhoz való hozzáférés a megbízás keretében elfogadott ellenőrzési szabályok szerint, a „szükség szerinti” elv alapján történik.

Kezdje a kívánt eredménnyel, a szolgáltatással vagy az érintett eszközökkel, a sürgősséggel, a határidőkkel, valamint az esetleges működési vagy szabályozási korlátozásokkal; ne küldjön bizalmas információkat, amíg az titoktartási megállapodás (NDA) és a biztonságos csatorna nem áll fenn. Ezt követően írásban rögzítjük a feladat hatókörét, a kizárásokat, a felhatalmazást, az együttműködési szabályokat, a teljesítési eredményeket, az átvételi feltételeket, a kapcsolattartókat és az ütemtervet.

A tervezett behatolási tesztek általában a feladatkör meghatározását és az írásbeli engedélyezést követő 3–5 munkanapon belül megkezdődhetnek, az aktuális kapacitás függvényében. Az aktív incidensek esetében a különálló, éjjel-nappal működő reagálási folyamatot alkalmazzuk, ezért vészhelyzetet haladéktalanul telefonon vagy biztonságos üzenetküldő csatornán keresztül kell jelentenie.

Az árképzés az eszközöktől, a részletességtől, a határidőktől, a kockázattól, a bizonyítékokra vonatkozó követelményektől és a teljesítendő feladatoktól függ. A feladat körének meghatározását követően írásbeli ajánlatot kap; egyértelműen meghatározott munkákra rögzített árú opciók állnak rendelkezésre, a fizetési feltételeket a szerződésben rögzítik, nagyobb projektek esetében pedig bankgaranciákról is tárgyalhatunk.

Az engedélyezett vizsgálati területek közé tartozhatnak a webalkalmazások, az API-k, a külső és belső hálózatok, az Active Directory, a felhőalapú környezetek, valamint a mobilalkalmazások. A szélesebb körű „red team” feladatok keretében az identitás-, személyi és fizikai ellenőrzési mechanizmusok is tesztelhetők, amennyiben ezekre a tevékenységekre kifejezett engedélyt adtak.

Nem. Az automatizált eszközök ugyan segíthetik a lefedettséget, de a folyamatot azok a szakemberek irányítják, akik feltérképezik a támadási útvonalakat, tesztelik az üzleti logikát, ellenőrzik a sebezhetőséget, és felmérik a valós hatásokat. Az eredmény pedig bizonyítékok és prioritás szerint rendezett javító intézkedések, nem pedig egy ellenőrizetlen szkennelési jelentés.

A tesztelés az OWASP és a PTES szabványoknak megfelelő gyakorlatokat követi, öt fázisban: a hatókör meghatározása és a részvételi szabályok, felderítés és a támadási felület feltérképezése, biztonságos kihasználás, kétlépcsős jelentéstétel, valamint az újratesztelés. A konkrét teszteseteket a megegyezés szerinti eszközökhöz és a fenyegetési modellhez igazítják.

Kizárólag azokat az eszközöket teszteljük, amelyekre írásbeli engedély és elfogadott működési szabályok vonatkoznak. Az ügyfélnek a rendszerek tulajdonosának kell lennie, vagy rendelkeznie kell az érintett tulajdonos vagy szolgáltató engedélyével; harmadik felek eszközei, a szociális manipuláció, a fizikai hozzáférés és a rongáló cselekmények nem tartoznak a vizsgálat hatálya alá, kivéve, ha azokat kifejezetten jóváhagyták.

A munkát úgy tervezték, hogy a zavarokat a lehető legkisebbre csökkentsék, de a tesztelés soha nem lehet teljesen kockázatmentes. A támadási ablakokat, a sebességkorlátozásokat, a kritikus rendszerek kizárását, az eszkalációs kapcsolattartókat, a leállítási feltételeket és a visszaállítási terveket előre egyeztetik, és kifejezett jóváhagyás nélkül nem hajtanak végre romboló jellegű ellenőrzéseket.

Az időtartam a feladat körétől, a hozzáféréstől, a komplexitástól és az ismételt tesztelés szükségességétől függ. A szolgáltatási oldalon tájékoztató jelleggel szerepelnek a következő kiindulási időtartamok: körülbelül két hét a webes és API-teszteléshez, három hét a hálózati teszteléshez, valamint hat hét a red-team gyakorlathoz; a tényleges ütemtervet az ajánlat tartalmazza.

Kap egy vezetői összefoglalót a vezetőség számára, valamint műszaki megállapításokat a mérnökök számára, beleértve a bizonyítékokat, az érintett eszközöket, a reális hatásokat, a súlyosságot és a prioritások szerint rendezett javítási útmutatásokat. A végleges feladatkör kiterjedhet továbbá a belső érdekelt felek számára szükséges beszámolókra, javítási műhelymunkákra vagy a bizonyítékok formátumára is.

Igen, a standard behatolási tesztelési munkafolyamat részeként szerepel a korábban egyeztetett és kijavított hibák újbóli tesztelése. A javaslatban rögzítik az újbóli tesztelés időkeretét, az érintett hibákat, a szükséges hozzáférési jogosultságokat, valamint azt, hogy a hitelesített javítások hogyan kerülnek feltüntetésre a zárójelentésben.

Nem. A behatolási teszt az engedélyezett hatókör időhatárolt értékelése, és nem bizonyítja, hogy nincsenek sebezhetőségek. Csökkenti a bizonytalanságot, és bizonyítékokon alapuló prioritásokat ad meg, de a biztonság továbbra is a javító intézkedésektől, az üzemeltetéstől, a felügyelettől és a jövőbeli változtatásoktól függ.

Igen. A 24 órás, hét napos incidenskezelő szolgáltatás feladata a fertőzés terjedésének megakadályozása, a bizonyítékok megőrzése, a bizonyítékok körének meghatározása, a fertőzés eltávolítása, a rendszer helyreállítása, valamint az incidens utáni biztonsági megerősítés. Aktív incidens esetén azonnal hívjon fel minket vagy használja a Signal alkalmazást, és kerülje el az érzékeny bizonyítékok nem jóváhagyott csatornákon történő továbbítását.

Nem. A DFIR-csoport a titkosítás nélküli adatlopásokkal és zsarolásokkal, az üzleti e-mail-fiókok feltörésével és a fizetési csalásokkal, a fiókátvételekkel, a Microsoft 365- vagy Google Workspace-fiókok és felhőalapú szolgáltatások feltörésével, a belső személyek által elkövetett esetekkel, valamint a feltört webalkalmazásokkal és szerverekkel is foglalkozik.

Válassza le az érintett eszközöket a hálózatról anélkül, hogy kikapcsolná őket, őrizze meg a felejtődő bizonyítékokat, védje meg a biztonsági másolatokat a további hozzáféréstől, rögzítse a végrehajtott műveleteket, és hozzon létre egy reagálási csatornát. Ne végezzen széles körű újraindítást, adat törlést, visszaállítást, visszafejtést vagy tárgyalásokat, amíg az incidenskezelő vezetője, valamint a jogi és biztosítási érdekelt felek nem állapodnak meg egy tervben.

Az incidenskezelő szolgálat 24 órás, hét napos ügyeleti rendszert működtet. A szolgáltatás szintje szerint az első hívástól számítva kevesebb mint 60 perc alatt csatlakozik egy elemző a közös ügyeleti rendszerhez, és a kezdeti helyzetkezelési útmutatás már a triázs során megkezdődik; a tényleges helyzetkezelési idő a hozzáféréstől, az incidens terjedelmétől, valamint az ügyfél intézkedésvégrehajtási képességétől függ.

Általában igen, bár a rendszer leállítása megsemmisítheti az olyan ideiglenes bizonyítékokat, mint a memóriában tárolt kulcsok, a rendszerbe bejuttatott folyamatok és az aktív kapcsolatok. Ne kapcsolják be újra a rendszereket; őrizzék meg azok jelenlegi állapotát, és vegyék fel a kapcsolatot a reagálócsapattal, hogy megtervezhessék a „cold-triage” eljárást és a többi bizonyítékforrás felderítését.

Nem. A helyreállítás a zsarolóvírus-családtól, a rendelkezésre álló kulcsoktól vagy visszafejtő programoktól, a bizonyítékok minőségétől, a biztonsági másolatok sértetlenségétől, a rendszer állapotától, a jogi korlátozásoktól, valamint attól függ, hogy a támadás után milyen mértékű tevékenység történt. Értékeljük a fertőzésmentes biztonsági másolatokat, az újratelepítést, a visszafejtő programokkal kapcsolatos kutatásokat és a kulcs-visszaállítási lehetőségeket, majd megállapítjuk, hogy mi állítható helyre, és mi nem.

A fizetés nem lehet az első lépés, és nem garantálja az ellopott adatok helyreállítását vagy törlését. Először a helyreállítási lehetőségeket és a bizonyítékokat kell felmérni; minden, a szolgáltatóval folytatott kommunikációban vagy fizetési döntésben be kell vonni az ügyfelet, a jogi tanácsadót, adott esetben a biztosítót, valamint engedélyt kell kérni a szankciók tekintetében.

A projekt terjedelmétől függően a szolgáltatások között szerepelhetnek a bizonyítékokról és a bizonyítékok láncolatáról szóló jegyzőkönyv, a beavatkozás idővonalának leírása, a kiváltó okok és az első hozzáféréssel kapcsolatos megállapítások, az oldalirányú mozgás és az adatkiszivárogtatás elemzése, a fertőzésre utaló jelek, a helyreállítási prioritások, valamint egy biztosítók vagy szabályozó hatóságok számára is alkalmas jelentés, amely tartalmazza a rendszer megerősítésére vonatkozó tervet. A következtetések továbbra is a megőrzött bizonyítékok és a betartott bizonyítékkezelési folyamat által korlátozottak.

Biztonságos Rust- és Python-alapú háttérrendszereket, API-kat, adatrendszereket, automatizálási megoldásokat, mesterséges intelligencia-integrációkat, adatmigrációkat, valamint biztonsági szempontból kritikus termelési szolgáltatásokat fejlesztünk. Ugyanez a mérnöki gyakorlat keretében készülnek az incidensekre szabott forenzikus adatgyűjtők, elemzőprogramok, idővonal-készítők, IOC- vagy YARA-szkennerek, valamint dekódoló és kulcs-visszaállító kutatási eszközök is.

A Rust-ot ott használják, ahol a memóriabiztonság, a párhuzamos futtatás, a kiszámítható teljesítmény és az alacsony szintű vezérlés fontos; a Python-t pedig ott, ahol a fejlesztési sebesség, az adatok, a gépi tanulás, az összehangolás és az integrációk játszanak fontos szerepet. Az architektúra-tervezés során a nyelvet komponensenként rendelik hozzá, ahelyett, hogy az egész rendszert egyetlen technológiai stackbe kényszerítenék.

A megvalósítási modell a következő szakaszokon halad át: felmérés, architektúra, megvalósítás, biztonsági megerősítés és átadás, a projekt keretében egyeztetett átvételi és teljesítménytesztekkel együtt. Az átadás kiterjedhet a forráskódra, a telepítési eszközökre, az API-szerződésekre, az architektúrával kapcsolatos döntésekre, az üzemeltetési útmutatókra, a diagramokra, a tudásátadásra, valamint – amennyiben a szerződés így rendelkezik – a bevezetést követő 30 napos támogatásra.

A tanácsadási szolgáltatások kiterjednek a biztonsági architektúrára, az üzleti szempontú kockázatértékelésre, a GDPR-nek való megfelelésre, az auditra való felkészülésre, az irányelvekre és az incidenskezelési folyamatokra, a biztonságos fejlesztés integrációjára, valamint a szerepkörökhöz igazodó képzésekre. A szolgáltatás keretében általában prioritás szerint rendezett megállapításokat, a felelősöket feltüntető kockázati nyilvántartást, biztonsági megerősítési ütemtervet, üzemeltetési kézikönyveket, valamint az auditra kész bizonyítékcsomagot állítunk össze.

Nem. A szabályozási megfelelésre való felkészültség technikai és üzemeltetési támogatást jelent, nem pedig jogi tanácsadást vagy tanúsítási garanciát; a számítógépes nyomozási eredmények a megőrzött bizonyítékoktól függenek; az adatok helyreállítása az incidens körülményeitől függ; a biztonsági tesztelés pedig nem bizonyíthatja a sebezhetőségek hiányát. Minden javaslat mérhető feladatokat és átvételi kritériumokat határoz meg anélkül, hogy a PWN-ALL befolyásán kívül eső eredményeket ígérne.

A PWN-ALL a Dark-Web és Leak Monitor szolgáltatást, a BotGuard bot-felismerőt, valamint a Vulnerability Scan Hubot különálló termékekként sorolja fel. Emellett több mint 20 ingyenes, böngészőalapú eszközt is kínál olyan feladatokhoz, mint a hash-képzés, a kulcsgenerálás, a szteganográfia, a zsarolóvírusok azonosítása, valamint a fájlok vagy a nyomozati adatok megtekintése; a kliensoldali eszközök a böngészőben futnak, anélkül, hogy a feldolgozott adatokat feltöltenék.

Állítsa vissza az érintett fiók jelszavát egy olyan eszközről, amelyről biztosan tudja, hogy nem fertőzött, ne pedig a feltört eszközről; jelentkezzen ki, és vonja vissza az összes aktív munkamenetet; távolítsa el az alkalmazásjelszavakat és a csatlakoztatott alkalmazások hozzáférési jogosultságait; majd kapcsolja be a többfaktoros hitelesítést. Őrizze meg a postafiókot a bejelentkezési és auditnaplókkal együtt, és ellenőrizze, hogy nincsenek-e rejtett továbbítási vagy postafiók-szabályok, de ne törölje az üzeneteket, a szabályokat vagy a fiókot, mert ezek bizonyítékul szolgálnak. Ha a támadás még mindig aktív, vagy pénzmozgás is szerepel az ügyben, hívja fel a 24/7-es vonalat, vagy használja a Signal alkalmazást, ahelyett, hogy a csevegőn várna. A DFIR-csapat teljes körűen kezeli a Microsoft 365, a Google Workspace és a fiókátvétel eseteit, a terjedés megfékezésétől a kiváltó ok feltárásán át a biztonsági megerősítésig.

Ez egy aktív üzleti e-mail-csalás és fizetési csalás esete, ezért a gyors reagálás döntő fontosságú – azonnal vegye fel a kapcsolatot a saját bankjával és a fogadó bankkal, hogy megpróbálják visszavonni vagy befagyasztani az átutalást, és jelentsék az esetet az illetékes hatóságoknak. Ne várjon a csevegőn, hanem jelezze nekünk a 24/7-es vonalon, különösen addig, amíg a pénzeszközök még mozgásban lehetnek. DFIR-csapatunk ezután kivizsgálja, hogyan fértek hozzá a postafiókhoz vagy a fiókhoz, módosították-e a számla- vagy banki adatokat, és mihez nyúltak még, miközben megőrzi a bizonyítékokat a bankja, a biztosítója és az esetleges szabályozó hatóságok számára. Tartsa meg érintetlenül az e-maileket és a fióknaplókat, és ne töröljön semmit, hogy a forenzikus kép teljes maradjon.

Ez titkosítás nélküli adatlopás és zsarolás, és egyértelműen a DFIR-csapat feladatkörébe tartozik, még akkor is, ha nem alkalmaztak zsarolóvírust. A legfontosabb feladat a bizonyítékok megőrzése, annak felmérése, hogy pontosan mire fértek hozzá és mit szivárogtattak ki, a hozzáférési útvonal lezárása, valamint a követelés megértése, mielőtt bárki is válaszolna a támadónak. Ne fizessen, ne tárgyaljon és ne válaszoljon a követelésre, amíg az incidenskezelés vezetője, valamint a jogi és biztosítási érintettek nem állapodnak meg a további lépésekről. Jelezze az esetet a 24/7-es vonalon, és a fenyegető üzeneteket biztonságos csatornán keresztül ossza meg, ne pedig nyilvános vagy nem jóváhagyott csatornán.

Ha jelzések vagy gyanú merül fel, de még nincs megerősített incidens, a DFIR-csapat átvizsgálja a naplófájlokat, a végpontokat, valamint a felhő- és identitásadatokat annak megállapítására, hogy vannak-e bizonyítékok jelenlegi vagy korábbi behatolásra, tartós jelenlétre vagy jogosulatlan adathozzáférésre. Ezt követően jelentést készít arról, hogy vannak-e a kompromittálódásra utaló jelek, és mi a teendő, és ha egyértelműen rosszindulatú tevékenységet talál, teljes körű incidenskezelési beavatkozásba kezd, amely magában foglalja a terjedés megfékezését és a forenzikus vizsgálatot. Amíg ez a felmérés folyik, őrizze meg a meglévő naplófájlokat, és kerülje a rendszerek újratelepítését vagy törlését, mivel ez törölheti a kérdés megválaszolásához szükséges bizonyítékokat. Ha aktív támadást észlel, azonnal hívja a 24/7-es vonalunkat, vagy lépjen kapcsolatba velünk a Signal alkalmazáson keresztül, ahelyett, hogy a csevegőn várna.

Minden beavatkozás magában foglalja az incidens utáni biztonsági megerősítést, miután a közvetlen fenyegetést elhárítottuk. A kiváltó okra és a kezdeti hozzáférésre vonatkozó megállapítások alapján a csapat egy prioritások szerint rendezett biztonsági megerősítési tervet ad át Önnek, amely megszünteti azokat a konkrét réseket, amelyeket a támadó kihasznált, és csökkenti egy ismételt támadás esélyét. A mélyebb, folyamatos munkához a tanácsadói gyakorlat ezt kockázati nyilvántartássá alakíthatja, amely tartalmazza a felelősöket, a frissített irányelveket és az incidenskezelési forgatókönyveket, valamint a szerepkörökhöz igazodó képzéseket, míg a mérnöki gyakorlat elkészítheti a javításokhoz szükséges eszközöket. A biztonsági megerősítés csökkenti a kockázatot és javítja az ellenállóképességet, de egyetlen szolgáltató sem ígérheti meg, hogy a jövőben nem fordulhat elő incidens.

A szolgáltatás helyreállítása fontos, de nem ad választ arra, hogy a támadó hogyan jutott be, még mindig jelen van-e, illetve milyen adatokhoz férhetett hozzá; ráadásul a helyreállítás felül is írhatja mindhárom kérdésre vonatkozó bizonyítékokat. Ha a kezdeti behatolási útvonalat és az esetleges tartós jelenlétet nem sikerül felderíteni és megszüntetni, ugyanaz a behatolás a helyreállítás után is megismétlődhet. Érdemes a DFIR-csapattal felderíteni a kiváltó okot, ellenőrizni, hogy maradt-e fenn hozzáférés, és megerősíteni, hogy milyen adatokat szivárogtattak ki, majd célzott biztonsági megerősítést alkalmazni – és a fennmaradó naplókat, lemezképeket vagy érintett adathordozókat megőrizni, ahelyett, hogy eldobná őket. Ha nem biztos abban, hogy a fenyegetés teljesen megszűnt-e, kezelje aktívként, és jelezze a 24/7-es vonalon.

A meglévő rendszerek egyértelműen a szolgáltatás hatálya alá tartoznak; a mérnöki gyakorlat rendszeresen vállal migrációs feladatokat, biztonsági megerősítést és biztonsági szempontból kritikus termelési szolgáltatásokat, nem csupán teljesen új rendszerek kiépítését. Egy megbízás egy felderítési szakasszal kezdődik, amelynek célja annak megállapítása, hogy a jelenlegi kód, adatok és bizalmi határok valójában hogyan működnek, mielőtt bármilyen változtatásra sor kerülne; ezt követi az architektúra kidolgozása, a megvalósítás, majd egy külön biztonsági megerősítési lépés. Amennyiben az elsődleges igény a meglévő alkalmazáskód biztonsági értékelése, azt alkalmazás-behatolási teszteléssel és a tanácsadói gyakorlat biztonságos fejlesztési integrációjával valósítjuk meg, és a megfelelő kombinációt már a kezdeti megbeszélés során határozzuk meg.

Az örökölt, részben kiépített vagy leállított rendszerek átvétele lehetséges, de a munka minden esetben egy felderítési szakasszal kezdődik, amelynek során megállapítjuk a rendszer tényleges jelenlegi állapotát: mi létezik, mi működik, és hol vannak a kockázatok és hiányosságok, mielőtt bármilyen megközelítést véglegesítenénk. Ezt követően a szokásos modell érvényesül az architektúra, a megvalósítás, a biztonsági megerősítés és az átadás során, melyek mindegyikét írásbeli munkaleírás szabályozza, előre egyeztetett átvételi kritériumokkal, nem pedig egy nyitott végű ígéret, hogy mindent kijavítunk. Azt, hogy mi valósítható meg reálisan, és milyen sorrendben, a jelenlegi állapot megértése után határozzuk meg.

A mesterséges intelligencia és az LLM integrációja a Rust és a Python mérnöki gyakorlatának kifejezett része, amelyet a tervezéstől kezdve biztonságosra építünk – ugyanazon a felderítési, architektúra-tervezési, megvalósítási és biztonsági megerősítési folyamaton keresztül, egyeztetett biztonsági és átvételi tesztekkel. Az LLM-funkciókra jellemző kockázatokat – például a modellhez eljutó megbízhatatlan bemeneti adatokat, az érzékeny adatok kiszivárgását, azt, hogy a modell mihez férhet hozzá, valamint a visszaélések és a költségek elszabadulásának kontrollját – a projekt hatókörében határozzuk meg, és a munka részeként kezeljük, nem pedig utólag illesztjük be. Mint minden biztonsági munkánál, a megbízás mérhető ellenőrzési intézkedéseket és átvételi kritériumokat határoz meg, ahelyett, hogy garantálná, hogy a rendszert nem lehet visszaélésszerűen használni.

Nem csupán egy puszta kódcsomagot kap – az átadás úgy van kialakítva, hogy az Ön környezetében telepíthető és üzemeltethető legyen, és magában foglalhatja a telepítési eszközöket, az API-szerződéseket, az architekturális döntéseket, az üzemeltetési útmutatókat, a diagramokat és a tudásátadást, valamint – amennyiben a szerződés így rendelkezik – a 30 napos indulás utáni támogatást is. Mivel a munka biztonsági szempontból kritikus éles környezetre irányul, az átadás előtt külön biztonsági megerősítési lépés is zajlik. Hogy pontosan ki végzi el és üzemelteti a telepítést, azt minden egyes megbízás esetében a munkaleírásban rögzítjük.

A biztonság beépítése a csapat meglévő szoftverfejlesztési folyamatába a tanácsadói gyakorlat biztonságos fejlesztési integrációja révén valósul meg, amely tanácsadói jellegű: felmérjük, hol illeszkedik a biztonság a meglévő munkafolyamatba, meghatározzuk a folyamatba tartozó ellenőrzéseket és védelmi korlátokat, valamint szerepkör-specifikus útmutatást adunk a fejlesztőknek. Amennyiben ehhez a folyamathoz egyedi automatizálásra vagy eszközök fejlesztésére van szükség – például testreszabott szkennerekre vagy ellenőrzésekre –, azt a mérnöki gyakorlat külön hatókörben valósíthatja meg. A tanácsadói gyakorlat tanácsot ad és meghatározza a folyamatot, de maga nem fejleszt szoftvert, így mindent, amit meg kell építeni, mérnöki feladatként határozunk meg.

A Rust és a Python a rendszer magját alkotja: a Rustot ott alkalmazzuk, ahol a memóriabiztonság, a párhuzamosság és a kiszámítható teljesítmény fontos, a Pythont pedig ott, ahol a fejlesztési sebesség, az adatok, a gépi tanulás és az integrációk számítanak. Az architektúra-tervezés során a nyelvet komponensenként rendeljük hozzá, ahelyett, hogy az egész rendszert egyetlen technológiai stackbe kényszerítenénk, és a meglévő rendszerek, illetve a migrációk is a hatókör részét képezik, így a megfelelő megoldást az Ön igényei alapján, a hatókör meghatározása során döntjük el.

A tanácsadás magában foglalja a GDPR-felkészülést és az auditra való felkészülést: a hiányosságok felmérését, az azok kiküszöbölésére szolgáló ellenőrzési intézkedéseket és irányelveket, valamint egy auditra kész bizonyítékcsomagot, mindezt gyártófüggetlen módon. Ez felkészülési és előkészítő támogatás, nem jogi tanácsadás, és önmagában nem garantálja a megfelelést vagy a tanúsítást – ezek az Ön működésétől és az értékelő szervtől függenek. Az eredmények: prioritás szerint rendezett megállapítások, a felelősöket feltüntető kockázati nyilvántartás, valamint egy megvalósítható biztonsági megerősítési ütemterv.

A szerepkör-specifikus biztonsági képzés a tanácsadói gyakorlat része, amelyet az Ön technológiai környezetéhez, kockázataihoz és az érintett szerepkörökhöz igazítunk. Ezt általában a kapcsolódó tanácsadói tevékenységekkel – a biztonságos fejlesztési integrációval, az irányelvekkel és az incidenskezelési folyamatokkal – kombináljuk, így a képzés tükrözi, hogy a csapatai a valóságban hogyan fejlesztenek és üzemeltetnek. Mint minden tanácsadásnál, a hatókört és a várható eredményeket előre egyeztetjük.

A biztonsági architektúra, illetve egy tervezett rendszerterv bevezetés előtti áttekintése a tanácsadói gyakorlat központi része. A tervet az Ön üzleti kockázatai és működési korlátai alapján értékeljük, majd prioritás szerint rendezett megállapításokat, egy biztonsági megerősítési ütemtervet, valamint – ahol hasznos – üzemeltetési kézikönyveket és a felelősöket megnevező kockázati nyilvántartást adunk át. Mivel a gyakorlat gyártófüggetlen, az ajánlások az Ön kockázatait követik, nem pedig egy olyan terméket, amelyet egyébként értékesíthetnénk.

A különbség a hatókörben rejlik: a tanácsadás gyártófüggetlen tanácsadói munka, amely felméri a kockázatokat, áttekinti az architektúrát és felkészíti Önt az auditokra, de nem fejleszt szoftvert és nem végez vészhelyzeti incidenskezelést. Ha kód megírására vagy rendszer megépítésére van szüksége, az a biztonságos szoftverfejlesztési gyakorlat; ha éppen támadás zajlik, az a 24 órás, hét napos incidenskezelési folyamat; ha pedig sebezhetőségek felderítésére és engedély melletti, biztonságos kihasználására van szüksége, az a behatolási tesztelés. Az elérni kívánt eredmény alapján a megfelelő gyakorlathoz irányítjuk, vagy kombináljuk azokat.

Elérhetők vagyunk e-mailben (PGP-vel is), a Signal alkalmazásban, a Telegramon a t.me/pwn_all címen, a WhatsAppon, illetve telefonon a +971 58 594 6337 számon; aktív incidensek esetén pedig a nap 24 órájában, a hét minden napján elérhető ügyeleti vonal áll rendelkezésre. Érzékeny ügyekben a Signal vagy a PGP-vel titkosított e-mail használatát javasoljuk, és kérjük, hogy ne küldjön titkokat vagy hitelesítő adatokat, amíg titoktartási megállapodás (NDA) és biztonságos csatorna nincs a helyén. Ha éppen incidens zajlik, ne várjon a csevegőn, hanem azonnal hívjon minket vagy használja a Signal alkalmazást.

Az Ön adataihoz való hozzáférés a megbízás keretében megállapodott ellenőrzési szabályok szerint, a „szükség szerinti” elv alapján történik; érzékeny részletek megosztása előtt titoktartási megállapodást (NDA) kötünk, és biztonságos csatornát biztosítunk. A konkrét kezelési, tárolási és megőrzési feltételeket ennek a megállapodásnak a részeként rögzítjük, nem pedig egységes, mindenre érvényes alapértelmezésként, ezért kérjük, hogy ne küldjön titkokat, amíg ezek nincsenek a helyén. Bármilyen érzékeny információ esetében a Signal vagy a PGP-vel titkosított e-mail a javasolt csatorna.

A közzétett bizonyítékunk a weboldal „Referenciák” szakaszában bemutatott, aláírt ajánlólevelek, amelyeket szívesen áttekinthet közvetlenül. Mivel a titoktartás számunkra elsődleges, ezen túlmenően nem írunk le konkrét ügyfeleket vagy eseteket, és bármilyen további részletet kizárólag az érintett ügyfél engedélyével és titoktartási megállapodás (NDA) keretében oszthatunk meg. Telefonon szívesen végigveszünk szemléltető, anonimizált példákat is arról, hogyan zajlik egy tipikus megbízás.

Nem, a weboldal és ez a csevegés tájékoztató jellegű, és nem minősül szerződésnek. Minden megbízást aláírt munkaleírás szabályoz, amely meghatározza a hatókört, a kizárásokat, a felhatalmazást, a megbízás szabályait, a teljesítendő feladatokat, az átvételi kritériumokat, a kapcsolattartókat és az ütemtervet; az árazást pedig a hatókör meghatározása után írásbeli ajánlatban rögzítjük. Semmilyen érzékeny információnak nem kell gazdát cserélnie, amíg titoktartási megállapodás (NDA) és biztonságos csatorna nincs a helyén.

Egy tipikus webes vagy API-megbízás a hatókör meghatározásával, a megbízás szabályainak rögzítésével és az írásbeli felhatalmazás megszerzésével kezdődik, majd a felderítéssel és a támadási felület feltérképezésével, a megállapodás szerinti célpontok biztonságos kihasználásával, a kétszintű jelentéstétellel, valamint a kijavított hibák újratesztelésével folytatódik. A szakemberek kézzel térképezik fel a támadási útvonalakat és igazolják a kihasználhatóságot, ahelyett, hogy nyers szkennerkimenetet adnának vissza, így Ön egy vezetői összefoglalót, bizonyítékokkal és súlyossági besorolással ellátott technikai megállapításokat, valamint prioritás szerint rendezett javítási útmutatást kap. A szolgáltatási oldal a webes és API-munkákra körülbelül kéthetes indikatív kiindulópontot ad meg, a tényleges ütemtervet és az újratesztelésre jogosult hatókört pedig az ajánlatban rögzítjük. Ez szemléltető vázlat; a pontos tesztesetek az engedélyezett eszközökhöz és a fenyegetésmodellhez igazodnak.

Egy tipikus eset a 24/7-es ügyeleti vonalon indul az incidens elszigetelésével és a bizonyítékok megőrzésével, majd forenzikus hatókör-meghatározással, amelynek célja a kiváltó ok, a kezdeti hozzáférés, az oldalirányú terjedés és a kiszivárogtatott adatok azonosítása. A helyreállítást a bizonyítékok által alátámasztottak alapján tervezzük meg – fertőzésmentes biztonsági másolatok, újratelepítés, valamint adott esetben visszafejtő programokkal kapcsolatos kutatás és kulcs-visszaállítási lehetőségek –, az ügyfél, a jogi tanácsadó és a biztosító bevonásával minden kifizetési vagy tárgyalási döntésbe. Ön megkapja a bizonyítékok láncolatának dokumentációját, a beavatkozás idővonalát, a kompromittálódás jeleit (IOC), a helyreállítási prioritásokat, valamint egy biztosítónak vagy szabályozó hatóságnak benyújtható jelentést, amely tartalmazza a biztonsági megerősítési tervet is. Ez szemléltető vázlat; a helyreállíthatóság a zsarolóvírus-családtól, a kulcsoktól, a biztonsági másolatoktól és a bizonyítékoktól függ, és semmi sem garantált.

Egy tipikus fejlesztés a felderítés, az architektúra, a megvalósítás, a biztonsági megerősítés és az átadás szakaszain halad át, az átvételi és teljesítményteszteket pedig már a projekt kezdetén előre egyeztetjük. A programozási nyelvet komponensenként választjuk ki – Rustot ott, ahol a biztonság és a teljesítmény fontos, Pythont pedig ott, ahol a sebesség, az adatok és az integrációk számítanak –, és a biztonságot már a tervezés során beépítjük, nem pedig utólag adjuk hozzá. Az átadás magában foglalhatja a forráskódot, a telepítési eszközöket, az API-szerződéseket, az architekturális döntéseket, az üzemeltetési útmutatókat, a diagramokat és a tudásátadást, valamint – amennyiben a szerződés így rendelkezik – a 30 napos indulás utáni támogatást. Ez szemléltető vázlat; a pontos hatókört és az átvételi kritériumokat a munkaleírás határozza meg.