- 5gsecurity - crysys.hu

Holnapi Nokia-CrySyS meeting
by Levente Buttyán 08 Jul '25

08 Jul '25

Sziasztok! Holnap úgy néz ki elég sokan szabin leszünk (én és Biczók Gergpő biztosan), ezért ha lehet a meetingünket kihagyhatnánk holnap. Elnézést a short notice-ért! Azért haladtunk a munkával a legutóbbi meeting óta, Dóri összefoglalóját a munkáról küldöm alább: A megbeszélésen odáig jutottunk, hogy ha a rendszerben előforduló szolgáltatások mindegyike csak egy másik szolgáltatástól függ, akkor hogyan számítható a hibaterjedés a rendszeren. Azóta azon dolgozunk, hogy ezt a hibaterjedési modell kiterjesszük arra az esetre, amikor egy-egy szolgáltatásnak több dependenciája is van és a dependenciák hibaállapotait aggregálnunk kell. Több lehetséges stratégiát is megvizsgáltunk. A naiv megoldás az lenne, ha a dependenciák minden lehetséges hibaállapot-kombinációját szimulálva kimérjük az eredő hibaállapotot. Ez nagyon pontos hibamodellt adna, viszont a sok mérés miatt elég rosszul skálázódik. Ehelyett inkább arra gondoltunk, hogy a dependenciák hibaállapotait, mint halmazt nézzük és ebből a halmazból választanánk a legrosszabb hibaállapotot, mint a továbbterjedő hibaállapot, vagyis worst-case-t számolnánk. Sajnos a hibaállapotok halmaza nem teljesen rendezhető, mert előfordulnak hibaállapotok, amelyek összehasonlításkor egyik dimenzióban jobbak, másikban rosszabbak. Pl. a "korrekt, de későn érkező válasz" hibáját kell összehasonlítanunk a "időben érkező, de hibás válasz" hibájával. Ezek között nem lehet általánosan, minden rendszerre igaz módon megmondani, hogy melyik rosszabb, mert ez az adott rendszer követelményeitől függ. Ezért azt javasoljuk, hogy az impact analízist egy-egy system capability-re (integrity, availability, ...) koncentrálva végezzük el. Az integrity fókuszú elemzéskor csak a helyes-helytelen válasz dimenzióban mozogva teljesen rendezhető a hibaállapotok halmaza: a helytelen válasz mindig rosszabb, mint a helyes. Availability-re fókuszálva is teljesen rendezhető a hibaállapotok halmaza: a normál időzítéssel érkező válasznál rosszabb a késve érkező válasz (delay: increased), aminél még rosszabb, ha néha időtúllépés miatt nem érkezik válasz (responsiveness: sometimes), de a legrosszabb, ha sose érkezik válasz időkorláton belül (responsiveness: never). Ennek a megközelítésnek nagy előnye, hogy csak páronként kell a hibaállapotok mérését elvégezni, az összesítést és elemzést plusz mérések nélkül el lehet végezni, vagyis remélhetőleg jól skálázódik. A hátránya viszont, hogy nem vesz figyelembe olyan eseteket, amikor a hibadimenziók hatnak egymásra, pl. helytelen válaszokat küldő dependencia miatt egy-egy szolgáltatás lelassul vagy kiesik. Még gondolkozunk, hogyan lehetne ezeket az eseteket skálázhatóak kezelni. Köszönettel: Levente -- Prof. Levente Buttyán Laboratory of Cryptography and System Security (CrySyS Lab) Department of Networked Systems and Services Budapest University of Technology and Economics (BME) https://www.crysys.hu/

2 2

Re: Holnapi megbeszélés 1 órával hamarabb
by Gergely Biczok 19 May '25

19 May '25

Szia Peter! Valtsunk akkor fazist, majus 22 csutortok 10.00 es onnan szamitva kethetente. Udv, Gergo On 15/05/2025 06:27, Levente Buttyán wrote: > Kedves Péter, > > Saknos ma 9-kor tanszéki értekezletünk lesz. Megbeszéljük házon belül, > hogy egy fázisváltás működne-e, mert most véget ér a szemeszter > szorgalmi időszaka, és a naptárunkban az óráink helye felszabadul. > Szóval nagyobb lesz a mozgásterünk nekünk is. > > Az viszont fontos, hogy a leveleket Biczók Gergely kollégámnak és > nekem küldjétek, mert valamelyikünk tud reagálni. > > Esetleg ha jónak látjátok, hozhatunk létre egy levelezési listát, hogy > ne maradjon ki senki, mint most (most Sándor József és én kaptuk a > levelet, Jocó egy PhD diák, én pedig lassan érek a napi levélfolyam > végére, szóval jobb lenne egy levelezési lista). Megcsináljuk mi. > > Üdvözlettel: > Levente > > > > On 14/05/2025 08:53, Peter 1. Szilagyi (Nokia) wrote: >> Sziasztok! >> >> Sajnos közbejött holnapra egy elhalaszthatatlan és nem általam >> koordinált megbeszélés a szokásos időpontunkban. Ez csak a holnapi >> alkalmat illeti. Tudnánk esetleg egy órával hamarabb, 9:00-tól kezdeni? >> >> Ha nem, hiszen nektek is be van táblázva a napotok, akkor jó lenne a >> szokásos 10:00 órás alkalom jövő hét csütörtökön (fázist váltva a >> kétheti sorozatban)? >> >> Üdv, >> >> Péter >> >

2 2

CrySyS Biweekly Synch
by Peter 1. Szilagyi (Nokia) 19 May '25

19 May '25

Új kétheti meeting sorozat. ________________________________________________________________________________ Microsoft Teams Need help?<https://aka.ms/JoinTeamsMeeting?omkt=en-US> Join the meeting now<https://teams.microsoft.com/l/meetup-join/19%3ameeting_MzgyMzRiM2EtZjEyZC00…> Meeting ID: 327 204 945 707 Passcode: nA2hJ7ZB ________________________________ Dial in by phone +36 1 999 9701,,760242915#<tel:+3619999701,,760242915> Hungary, Budapest Find a local number<https://dialin.teams.microsoft.com/5a21d3c8-6512-4a91-a983-d3679042eed2?id=…> Phone conference ID: 760 242 915# Join on a video conferencing device Tenant key: teams(a)vc.nokia.com Video ID: 122 656 464 3 More info<https://pexip.me/teams/vc.nokia.com/1226564643> For organizers: Meeting options<https://teams.microsoft.com/meetingOptions/?organizerId=745b1553-4507-4a08-…> | Reset dial-in PIN<https://dialin.teams.microsoft.com/usp/pstnconferencing> -- Note that attendee's phone number is visible for the meeting organizer when connected by phone. Do not manually delete or change any information in this section -- Privacy and security<https://nok.it/TeamsPrivacy1> ________________________________________________________________________________

1 0