ISO 27001 A melléklet: a 93 kontroll működésbe állítása

Az A melléklet hasznos referenciakészletet ad a biztonsági csapatoknak. Operatív értéke abból fakad, hogy megmutatja, miért alkalmazandó egy kontroll, hogyan valósították meg, és milyen bizonyíték támasztja alá az Ön környezetében. Egy 93 zöld állapotjelzőt tartalmazó nyilvántartás nem elég, ha senki sem tudja megmagyarázni, mely rendszerekre vonatkoznak ezek a jelzők.

Egy technológiai igazgató számára a gyakorlati kihívás az, hogy a kontrollok célját mérnöki és operatív munkává alakítsa anélkül, hogy az információbiztonsági irányítási rendszer párhuzamos bürokráciává válna. A hozzáférési felülvizsgálatoknak valós jogosultsági adatokat kell használniuk. A helyreállítási terveknek a szolgáltatási függőségeket kell tükrözniük. A beszállítói értékeléseknek azokkal a szolgáltatásokkal kell foglalkozniuk, amelyeket az üzlet ténylegesen igénybe vesz.

Ez az útmutató bemutatja, hogyan válassza ki a kontrollokat, hogyan ossza el a felelősségeket, hogyan határozza meg a megvalósításokat, és hogyan tesztelje az ezekből eredő állításokat. Az alábbi felülvizsgálati gyakoriságok és megvalósítási példák gyakorlati ajánlások, nem a szabvány által előírt egységes időközök.

Értse meg, mire szolgál az A melléklet – és mire nem

Az ISO/IEC 27001:2022 A melléklete 93 kontrollt tartalmaz négy témakörben. A 4–10. fejezet tartalmazza az irányítási rendszerre vonatkozó követelményeket: a szervezet környezetét, a vezetést, a tervezést, a támogatást, a működtetést, a teljesítményértékelést és a fejlesztést. Az A melléklet a kontrollok kiválasztását támogatja; nem helyettesíti ezeket a követelményeket vagy az Ön kockázatértékelését.

Ez a megkülönböztetés a megvalósítás során számít. Egy biztonsági mentési konfiguráció támogathat egy kiválasztott kontrollt, de nem bizonyítja, hogy meghatározták az IBIR alkalmazási területét, értékelték a kockázatokat, belső auditot végeztek vagy lezajlott a vezetőségi átvizsgálás. Ezek különálló tevékenységek, különálló bizonyítékokkal.

A kontrollok kiválasztása kockázatalapú. Határozza meg a kockázatok kezeléséhez szükséges kontrollokat, majd vesse össze őket az A melléklettel, hogy ellenőrizze, nem maradt-e ki szükséges kontroll. Az A mellékleten kívüli további kontrollokra is szükség lehet. Fordítva: indokolt kizárás is lehetséges; nincs olyan szabály, hogy minden szervezetnek ki kellene zárnia valamit, vagy pontosan ugyanazt a kiválasztást kellene megvalósítania.

Az ISO/IEC 27002:2022 megvalósítási útmutatást ad a kontrollokhoz. Attribútumai segítenek rendszerezni őket kontrolltípus, információbiztonsági tulajdonság, kiberbiztonsági koncepció, operatív képesség és biztonsági terület szerint. Ezek hasznos szűrési segédletek, nem további tanúsítási ellenőrzőlisták. A mérvadó szövegezéshez a licencelt szabványokat használja.

Használja a négy témakört a megfelelő gazdák megtalálásához

A témakörök navigációs struktúrát adnak, nem négy független munkafolyamatot. Egy kilépési folyamat például összekapcsolja a munkaviszonnyal kapcsolatos felelősségeket, az identitáskezelést, az eszközök visszaadását és az alkalmazásokhoz való hozzáférést.

Szervezeti kontrollok: kapcsolja össze az irányítást az operatív döntésekkel

Ezek a kontrollok a szabályzatokra, a felelősségekre, a feladatkörök szétválasztására, az eszközökre, az információk osztályozására és kezelésére, a hozzáférés-irányításra, a beszállítókra, az incidensekre, a folytonosságra, a jogi kötelezettségekre és a felülvizsgálati tevékenységekre terjednek ki.

Kezdje annak azonosításával, hol születnek a döntések. Ki hagy jóvá egy új felhőszolgáltatást? Ki rendel hozzá információbiztonsági osztályba sorolást? Ki dönti el, hogy egy bejelentett esemény incidens-e? Egy szabályzatnak megismételhetővé kell tennie ezeket a döntéseket és ki kell osztania a döntési jogköröket, ahelyett hogy csupán a biztonság iránti támogatást fejezné ki.

A beszállítói biztonsághoz szolgáltatásspecifikus bizonyítéklánc szükséges: a szolgáltatás üzleti célja, az általa kezelt információk, az értékelt kockázatok, a szerződéses felelősségek és a folyamatos felülvizsgálat. Egy beszállító megbízhatósági jelentése alátámaszthatja ezt az értékelést, de hatókörének, időszakának és az ügyféloldali felelősségeknek meg kell felelniük az Ön felhasználásának.

Az incidenskezeléshez hasonlóképpen többre van szükség, mint egy vészhelyzeti kapcsolattartói listára. Határozza meg a bejelentési utakat, az értékelési szempontokat, a reagálási jogköröket, a bizonyítékok kezelését és a tanulási tevékenységeket. Rögzítse a gyakorlatokat vagy a tényleges reagálásokat, beleértve a nyomon követési teendőket és azok gazdáit.

Személyi kontrollok: tegye a munkaviszonnyal kapcsolatos eseményeket megbízható kiváltó pontokká

A nyolc személyi kontroll az előzetes ellenőrzéssel, a munkaszerződési feltételekkel, a tudatossággal és képzéssel, a fegyelmi eljárásokkal, a munkaviszony változása utáni felelősségekkel, a titoktartással, a távmunkával és az események bejelentésével foglalkozik.

Építse be ezeket a meglévő munkaügyi munkafolyamatokba. Egy belépő munkatársnak megfelelő kötelezettségekre, hozzáférésre és tájékoztatásra van szüksége. Egy munkakört váltó munkatárs jogosultságait újra kell értékelni, nem egyszerűen kiegészíteni. Egy kilépő munkatársnál meg kell szüntetni a hozzáférést, vissza kell venni az eszközöket, és egyértelművé kell tenni a továbbra is fennálló titoktartási kötelezettségeket.

A felelősség gyakran több csapatot érint. A HR kezdeményezhet egy kilépést, az identitáskezelő adminisztrátorok letiltják a központi fiókot, az alkalmazásgazdák eltávolítják a helyben kezelt hozzáféréseket, egy vezető pedig megerősíti a befejezést. Ha a teljes folyamatot a biztonsági területre bízzák, ezek a függőségek rejtve maradnak.

Hasznos bizonyíték lehet a jóváhagyott munkafolyamat-nyilvántartás, a képzések teljesítése és a késedelmes teendők nyomon követése, az elfogadott feltételek, valamint a mintavétellel ellenőrzött munkaviszony-változások. Korlátozza az érzékeny HR-bizonyítékokhoz való hozzáférést; egy kontrollellenőrnek nincs automatikusan szüksége a teljes személyi anyagokra.

Fizikai kontrollok: dokumentálja a saját és a beszállító határait

A fizikai kontrollok a helyiségekkel, a belépéssel, a megfigyeléssel, a környezeti fenyegetésekkel, a biztonságos területekkel, az íróasztalokkal és képernyőkkel, a berendezésekkel, az adathordozókkal, a közművekkel, a kábelezéssel, a karbantartással és a selejtezéssel foglalkoznak.

Egy felhőközpontú szervezetnek is foglalkoznia kell a fizikai biztonsággal. A megvalósítás egy részét a felhőszolgáltató biztosíthatja, míg az irodai belépés és a munkavállalói eszközök a szervezet saját felelősségében maradnak. Ezt a megosztást rögzítse, ahelyett hogy automatikusan kizárná a teljes témakört.

A saját telephelyein azonosítsa, ki léphet be, hogyan változik a hozzáférés, hol vannak az érzékeny berendezések, és hogyan kezelik a látogatókat. A távoli eszközöknél határozza meg a kockázataiknak megfelelő tárolási, szállítási, javítási és selejtezési szabályokat.

Bizonyíték lehet például a belépési engedélyek nyilvántartása, a látogatókezelési eljárások, az eszközleltárak és a selejtezési nyilvántartások. A beszállítói bizonyítékoknak meg kell magyarázniuk a lefedett létesítményeket és szolgáltatásokat; nem szabad őket az Ön irodájára vagy laptopjaira vonatkozó kontrollok bizonyítékaként kezelni.

Technológiai kontrollok: a lefedettséget az eszközök kiválasztása előtt határozza meg

A technológiai témakör a végpontokra, a kiemelt jogosultságú hozzáférésre, a hitelesítésre, a forráskódhoz való hozzáférésre, a kapacitásra, a kártevőkre, a sérülékenységekre, a konfigurációkra, az adatkezelésre, a biztonsági mentésekre, a rugalmasságra, a naplózásra, a monitorozásra, a hálózatokra, a kriptográfiára, a fejlesztésre és a változáskezelésre terjed ki.

Kezdje a rendszerek lefedettségével. Egy identitáskezelési szabályzat hiányos, ha az éles hozzáférés, a szolgáltatásfiókok vagy egy külön kezelt alkalmazás kívül esik a megvalósításán. Egy naplózási platform hiányos, ha a kritikus események soha nem jutnak el hozzá, vagy senki sem reagál a riasztásokra.

A szoftverfejlesztésnél kapcsolja össze a követelményeket és a tervezési döntéseket a kódátvizsgálással, a biztonsági teszteléssel, a környezetek szétválasztásával, a tesztadatok kezelésével és a kiadás jóváhagyásával. A fenyegetésmodellezés segíthet a biztonsági követelmények azonosításában a megvalósítás előtt. A tesztelés mélységének a kockázatot és a kötelezettségeket kell követnie; az ISO 27001 nem ír elő egységes behatolásteszt-ütemtervet.

A kriptográfiánál különböztesse meg a tárolt és a továbbított adatokat, és dokumentálja a kulcsok gazdáit, a hozzáférést, a helyreállítást, a rotációt és a visszavonást. A „titkosítás bekapcsolva” fontos megvalósítási kérdéseket hagy megválaszolatlanul.

Mi változott 2022-ben, és hol érdemes hiányosságokat keresni

A 2013-as kiadás 114 kontrollt tartalmazott 14 területen. A 2022-es kiadás 93 kontrollba szervezte át őket négy témakörben, köztük 11 új kontrollal. Az alacsonyabb szám nem jelent kevesebb biztonsági munkát: az összevonás több operatív felelősséget is egyetlen hivatkozás alá helyezhet.

Egy régebbi nyilvántartás frissítésekor őrizze meg a mögöttes megvalósításokat és bizonyítékokat, ahelyett hogy csupán az azonosítókat cserélné le. Ellenőrizze, hogy az új csoportosítás megváltoztatja-e a lefedettséget, a felelősségeket vagy az állapot alátámasztásához szükséges teszteket.

Az akkreditált ISO/IEC 27001:2013 szerinti tanúsítások átállási határideje 2025. október 31. volt. Ezek a tanúsítványok már nem érvényesek; a kontrollnyilvántartás frissítése önmagában nem igazolja a 2022-es kiadás szerinti tanúsítást.

Az alábbiak gyakorlati kiindulópontok a 11 új kontrollhoz, nem a mérvadó szövegük reprodukciói.

Ne kezelje ezeket tizenegy automatikus termékbeszerzésként. A fenyegetésekre vonatkozó információkhoz például elemzésre és cselekvésre van szükség, nem csupán egy előfizetett adatfolyamra. Az adatok törléséhez ismerni kell a másolatokat, a biztonsági mentéseket és a megőrzési kötelezettségeket, nem elég egy törlés gomb. A monitorozáshoz operatív reagálási útvonal kell.

Rögzítse külön az alkalmazhatóságot és a megvalósítást

Az alkalmazhatósági nyilatkozatnak (SoA) azonosítania kell a szükséges kontrollokat, meg kell magyaráznia a bevonásukat, rögzítenie kell, hogy megvalósultak-e, és meg kell indokolnia az A melléklet kontrolljainak kizárását. Ezek a követelmények az ISO/IEC 27001 kockázatkezelési rendelkezései között szerepelnek.

Ha mind a 93 hivatkozást felülvizsgálati indexként használja, az gyakorlati módja annak, hogy az összevetés ellenőrizhető legyen. Vegye fel az egyéb szükséges kontrollokat is. Az alkalmazhatósági nyilatkozat nem kockázatnyilvántartás, kockázatkezelési terv vagy bizonyítéktár, bár adott esetben mindegyikhez kapcsolódnia kell.

Minden alkalmazandó kontrollnál rögzítse:

• A bevonást alátámasztó kockázatokat vagy kötelezettségeket.
• Az érintett rendszereket, helyszíneket, információkat és folyamatokat.
• A tényleges megvalósítást és az elszámoltatható gazdát.
• Az alátámasztó bizonyítékokat és azok felülvizsgálati időszakát.
• A függőségeket, a kivételeket és a befejezetlen munkát.
• A következő felülvizsgálat dátumát vagy kiváltó eseményét.

Tartsa függetlenül az alkalmazhatóságot a megvalósítás állapotától. Az „alkalmazandó, részben megvalósított” őszinte és hasznos bejegyzés. A „nem alkalmazandó, mert még nem vásároltunk eszközt” nem alkalmazhatósági indoklás.

Egy kizárásnak le kell írnia azokat a hatóköri tényeket, amelyek a kontrollt szükségtelenné teszik, és összhangban kell maradnia a kockázatértékeléssel. A „nem fejlesztünk szoftvert” állítást alaposan meg kell vizsgálni, ha egy alvállalkozó fejleszti az ügyfélportálját. A kiszervezés megváltoztatja a megvalósítás és a bizonyítékok útját; nem szünteti meg automatikusan a kockázatot.

Elosztott megvalósítások esetén rögzítse a megosztást. Egy fizikai védelmi kontroll függhet a beszállító által üzemeltetett tárhelyszolgáltatási létesítményektől, a vállalat által kezelt irodai belépéstől és attól, hogyan bánnak a munkavállalók az eszközökkel. Egy gazda elszámoltatható maradhat az összesített állításért, miközben a tevékenységeket különböző csapatok végzik.

Egy hasznos megvalósítási leírás elég konkrét ahhoz, hogy tesztelni lehessen: „Az éles rendszerek adminisztrátorai névre szóló, jóváhagyott hozzáférést kapnak az identitásszolgáltatáson keresztül; a vészhelyzeti hozzáférést külön naplózzák és felülvizsgálják.” A „a hozzáférést biztonságosan kezeljük” nem tud iránymutatást adni sem egy mérnöknek, sem egy ellenőrnek.

Tesztelje az állapot mögötti állítást

Egy szabályzat a szándékolt viselkedést írja le. Bizonyíthatja a kialakítást és a jóváhagyást, de önmagában nem bizonyíthatja a működést. Építsen bizonyítékláncot a követelménytől a megvalósított mechanizmusig, majd egy megfigyelt eredményig.

A hozzáférés-kezelésnél vesse össze a jóváhagyott szabályokat a felhasználók tényleges jogosultságaival és a kilépési nyilvántartásokkal. Adott esetben vonja be a kiemelt jogosultságú identitásokat, a nem emberi fiókokat és a központi identitáskezelésen kívül eső alkalmazásokat is. Rögzítse a sokaságot, a mintát és a kivételeket, ahelyett hogy egyetlen kényelmes képernyőképet mutatna be.

A biztonsági mentéseknél vizsgálja meg a konfigurációt és egy visszaállítás eredményét. Egy sikeres mentési feladat kevesebbet bizonyít, mint a használható információk sikeres helyreállítása. Ellenőrizze a jogosultságokat, a függőségeket és a helyreállítási célokat; egy titkosítási kulcsai nélkül visszaállított adatbázis nem feltétlenül állítja helyre a szolgáltatást.

A beszállítói biztonságnál kapcsolja az értékelést az adott szolgáltatáshoz és a szerződéses felelősségekhez. Vizsgálja meg, hogy a bizonyíték lefedi-e az Ön által használt szolgáltatást, és hogy az azonosított ügyféloldali felelősségek megvalósultak-e.

Egy gyakorlati tesztnyilvántartásnak tartalmaznia kell a várt eredményt, a módszert, a hatókört, a bizonyíték dátumát, az ellenőrt, az eredményt és a nyomon követési döntést. Különböztesse meg:

• Kialakítás: a javasolt mechanizmus kezeli az azonosított kockázatot.
• Megvalósítás: a mechanizmus a megadott teljes hatókörben létezik.
• Működés: a nyilvántartások mutatják, hogy az érintett időszakban működött.
• Hatékonyság: a tesztelés azt mutatja, hogy eléri a kívánt eredményt.

Bizonyíték lehet konfiguráció, export, jegy, szerződés, interjú és fizikai megfigyelés. Olyan bizonyítékot válasszon, amely a tényleges állítást támasztja alá. Egy konfigurációs export az aktuális beállításokat mutathatja; a korábbi jegyek azt mutathatják, hogy a kivételeket idővel kezelték-e.

Őrizze meg az eredetre vonatkozó adatokat: a forrásrendszert, a gyűjtés dátumát, a lefedett időszakot és az esetleges szűrést. A titkokat vagy személyes adatokat tartalmazó bizonyítékokat hozzáférési korlátozásokkal és megfelelő kitakarással védje. A bizonyítékgyűjtés nem hozhat létre újabb, ellenőrizetlen tárat érzékeny adatokból.

Kidolgozott példa: a kilépési folyamat ellenőrizhetővé tétele

Vegyünk egy szemléltető SaaS-vállalatot 45 munkavállalóval, egy irodával, felhőalapú tárhellyel, központilag kezelt identitással és két, helyi fiókokat használó alkalmazással. Ezek a példához tartozó feltételezések, nem a Secani ügyfeleinek eredményei.

A kockázat az ügyfél- vagy vállalati információkhoz való hozzáférés fennmaradása a kilépés után. A releváns kontrollok közé tartoznak a munkaviszony változásával kapcsolatos felelősségek, az identitáskezelés, a hozzáférési jogok és az eszközök visszaadása. A műszaki hitelesítés és a hozzáférési korlátozások szintén támogatják a megvalósítást.

A vállalat a kontrollt alkalmazandóként rögzíti. A kilépés kiváltó eseményéért a HR felel; az identitással és az eszközökkel kapcsolatos teendőkért az IT; a helyi fiókok eltávolításáért az egyes alkalmazásgazdák. A munkavállaló vezetője megerősíti a kilépés szükséges időzítését. A biztonsági gazda felülvizsgálja a folyamatot és a nyitott kivételeket.

A megvalósítás magában foglal egy jóváhagyott kilépési jegyet, a központi fiók ütemezett letiltását, a munkamenetek visszavonását, ahol ez támogatott, a helyi fiókok eltávolítását, az eszközök visszavételét, valamint azoknak a hitelesítő adatoknak az ellenőrzését, amelyeket az érintett személy kezelt. A közös titkokat szükség esetén lecserélik; a személyes fiókokat nem adják át csak úgy egy utódnak.

A bizonyítékcsomag összekapcsolja a jóváhagyott eljárást, a kilépési jegyet, a fiókműveletek nyilvántartását, a helyi alkalmazásokra vonatkozó megerősítéseket és az eszköznyilvántartást. Minden elem az állítás egy meghatározott részét támasztja alá.

Egy szemléltető felülvizsgálat során a csapat négy kilépést vizsgál meg. A központi fiókokat az ütemezés szerint letiltották, de az egyik helyi alkalmazásban két napig megmaradt a hozzáférés. A kontrollt nem nyilvánítják teljes mértékben hatékonynak pusztán a központi identitásra vonatkozó bizonyítékok alapján.

Az alkalmazásgazda eltávolítja a fiókot, megvizsgálja, történt-e hozzáférés, és rögzíti az eredményt. A csapat felveszi az alkalmazást a kilépési ellenőrzőlistára, és egyeztetési lépést rendel hozzá. A kockázatkezelési intézkedés gazdát és határidőt kap; egy későbbi teszt ellenőrzi, hogy a módosított munkafolyamat működik-e.

Ez a példa megmutatja, miért kell a bizonyítékoknak követniük a függőségeket. Ha négy rendszer „kész” állapotot jelez, az nem igazolja a befejezést, ha egy ötödik rendszert soha nem vontak be.

Tartsa működésben a kontrollokat a felülvizsgálatok között

A kontrollok változnak, amikor a rendszerek, a beszállítók, az emberek és az üzleti követelmények változnak. Az ütemezett felülvizsgálatok mellett határozzon meg felülvizsgálatot kiváltó eseményeket a jelentős kiadásokra, az új szolgáltatásokra, az irodai változásokra, az incidensekre és a módosult kötelezettségekre.

A változékonysághoz és a kockázathoz illő gyakoriságot alkalmazzon. A kiemelt jogosultságú hozzáféréssel kapcsolatos kivételek gyors felülvizsgálatot igényelhetnek, míg egy stabil szabályzatnál hosszabb ciklus is elegendő lehet, változáshoz kötött kiváltó eseményekkel kiegészítve. Ezek vezetői döntések, nem az A melléklet által előírt egységes gyakoriságok.

Kövessen nyomon néhány hasznos mutatót: a késedelmes javításokat, a lefedetlen rendszereket, a nyitott bizonyítéki kivételeket és a sikertelen kontrollteszteket. Ezeket válassza el a dokumentumszámlálástól. Egy nagy bizonyítéktár mellett is maradhat teszteletlen egy kritikus éles környezet.

A belső audit az IBIR külön értékelését biztosítja; a kontrollgazdák rutinszerű felülvizsgálatai nem helyettesítik. A vezetőségi átvizsgáláshoz is a teljesítményre, a változásokra, az erőforrásokra és a fejlesztésre vonatkozó vezetői döntésekre van szükség, nem csupán egy kitöltött kontrolltáblázatra. A tanúsítást független tanúsító szervezet végzi, nem az ISO vagy egy szoftverszolgáltató.

Gyakori hibák: mindent a biztonsági területre bízni, egy másik szervezet kizárásait átmásolni, beszállítói tanúsítványokra hagyatkozni a hatókör ellenőrzése nélkül, és a megállapításokat akkor lezárni, amikor egy szabályzat megváltozik, nem pedig akkor, amikor a módosított folyamatot már tesztelték.

Kezdje egy szolgáltatással és egy teljes bizonyítéklánccal

Válasszon ki egy reprezentatív szolgáltatást, és kövesse végig annak rendszereit, szolgáltatóit, információit és operatív gazdáit. Válasszon ki néhány kapcsolódó kontrollt – például a hozzáférést, a változáskezelést, a naplózást és a helyreállítást –, és mindegyik megvalósítását tegye ellenőrizhetővé, mielőtt kibővítené a nyilvántartást.

A Secani ezt a munkafolyamatot azzal támogatja, hogy modellezi a rendszereket és a függőségeket, összekapcsolja a bizonyítékokat a követelményekkel, a kontrollokkal és a döntésekkel, és a hiányosságokat feladatként követi nyomon. Jelöljön ki gazdát és ellenőrt, csatolja a meglévő nyilvántartásokat, és őrizze meg az átvizsgálási megjegyzéseket és jóváhagyásokat. A mesterséges intelligenciával támogatott összerendeléseket vagy összefoglalókat kezelje vázlatként: validálja a forrásokat, és tartsa egyértelműnek az emberi jóváhagyást. A strukturált auditfelkészültség bemutatja a mögöttes bizonyítékmodellt.

Az első eredménynek egy koherens láncnak kell lennie a kockázattól a kontrollig, a megvalósításig, a bizonyítékig, a teszteredményig és a nyomon követési döntésig. Ezt a láncot aztán a fennmaradó hatókörben megismételheti, anélkül hogy az A melléklet minden hivatkozásához új folyamatot kellene kitalálnia.

Gyakorlati kérdések

Alátámaszthat-e egy nyilvántartás több kontrollt is?

Igen. Egy kilépési jegy több kapcsolódó kontrollt is alátámaszthat. Magyarázza el, melyik állítást támasztja alá az egyes kontrolloknál; a bizonyíték közös használata nem teszi azonossá a kontrollokat.

Minden kontrollnak saját szabályzattal kell rendelkeznie?

Nem. A szabályzatokat és eljárásokat érthető operatív folyamatok köré szervezze. Egy dokumentum több kontrollt is lefedhet, feltéve hogy a felelősségek és a megvalósítás egyértelműek maradnak.

Honnan kell származnia a mérvadó kontrollistának?

Az A melléklet szövegezéséhez a licencelt ISO/IEC 27001 szabványt, a megvalósítási útmutatáshoz pedig az ISO/IEC 27002 szabványt használja. Az operatív összefoglalók hasznos navigációs segédletek, nem helyettesítik a szabványokat.