Управление на мобилни устройства: конфигурация и доказателства

Управлението на устройства подпомага сигурността само за устройствата и настройките, които действително обхваща. Табло на MDM, показващо съответстващи устройства, изисква втори въпрос: кои устройства липсват? Следва и трети въпрос: дали „съответстващо“ описва ефективна конфигурация, или просто политика, възложена на крайно устройство?

За CTO задачата е тези отговори да бъдат възпроизводими. Управлението на мобилни устройства трябва да свързва собствеността върху устройствата, конфигурацията, достъпа до приложенията, реагирането при инциденти и доказателствата. Целта не е зелено табло. Целта е защитимо описание на това кои крайни устройства имат достъп до бизнес информация, как са защитени и какво се случва, когато защитата се провали.

Какво контролира MDM и какво не

Управлението на мобилни устройства е администрирането на крайни устройства чрез централна услуга и механизми за управление, поддържани от платформата. В зависимост от продукта, операционната система и режима на регистриране то може да внедрява конфигурационни профили, да разпространява приложения, да докладва състоянието на устройствата, да ограничава избрани функции и да изпраща дистанционни команди. По-широките продукти за управление на крайни устройства може да включват лаптопи и настолни компютри наред с телефоните и таблетите.

Тези възможности не са еднакви. Напълно управляван служебен телефон и личен телефон с управляван служебен профил предлагат различни контроли и телеметрия. Някои платформи използват вградени услуги за управление; други изискват допълнителни агенти. Не бива да се предполагат нито постоянна свързаност, нито незабавно изпълнение.

MDM също така не замества управлението на самоличности, откриването на заплахи в крайни устройства, управлението на уязвимости или класификацията на информацията. Той може да конфигурира тези контроли или да им предоставя сигнали, но тяхното функциониране изисква отделна проверка. Управлявано устройство все пак може да има прекомерни права в приложения, неотменена сесия или уязвимо приложение.

Преди да изберете настройки, определете твърдението за контрола. Например: „Служебните лаптопи с достъп до производствената среда за администриране трябва да са регистрирани, криптирани, поддържани и наскоро оценени.“ Това твърдение посочва съвкупност, ресурс и наблюдаеми условия. „Всички устройства са сигурни“ не го прави.

Свържете управлението на крайни устройства с ISMS

ISO/IEC 27001 се отнася до система за управление на информационната сигурност с определен обхват, а не до закупуването на конкретен инструмент за крайни устройства. Нейните клаузи 4–10 определят изискванията към системата за управление. Приложение A предоставя референтен набор от 93 контрола, чиято приложимост се преценява чрез оценката и третирането на риска; то не е универсален контролен списък за конфигурация на MDM.

Декларацията за приложимост записва необходимите контроли, обосновката за включването им, статуса на внедряване и обосновката за изключване на контроли от приложение A. Внедряването на MDM осигурява част от изпълнението и доказателствата за съответните контроли, а не доказва цялата ISMS.

Полезни връзки са:

Тези съответствия описват приноси, а не равностойност. Например внедряването на конфигурация за влизане не доказва, че привилегированият достъп е подходящо одобрен. Използвайте нашето ръководство за приложение A, за да свържете мерките за крайни устройства с по-широката ISMS, вместо да третирате съответствието на устройствата като изолиран резултат.

Определете съвкупността, преди да измервате съответствието

Започнете с устройствата, които съхраняват, обработват или имат достъп до информация в обхвата на ISMS. Включете служебното и личното оборудване, крайните устройства на изпълнители, споделените устройства и временно заеманите устройства, когато е относимо. Договорете поддържаните операционни системи, правилата за регистриране и границите на поверителността.

Изградете инвентара около стабилни идентификатори, а не само около показваните имена. Полезни полета са идентификатор на актива, идентификатор в системата за управление, възложен потребител, собственост, платформа, режим на регистриране, бизнес цел, дата на регистриране, последен контакт и статус на извеждане от употреба. Изрично записвайте отговорниците за споделените устройства.

Сверете инвентара в MDM с независими източници. Записите за закупуване на активи разкриват оборудване, което никога не е било регистрирано. Записите за влизане от доставчика на самоличности и журналите за достъп до приложения могат да разкрият крайни устройства, които липсват в управлението. Записите от защитата на крайните устройства могат да покажат дублирани агенти или устройства, управлявани другаде. Проверете какви идентификатори действително предоставя всеки източник, преди да опитате да ги съпоставите.

Класифицирайте несъответствията, вместо мълчаливо да ги изключвате:

• В обхвата и регистрирани: оценете конфигурацията и актуалността.
• В обхвата, но неуправлявани: регистрирайте, ограничете достъпа или одобрете ограничено изключение.
• Изведени от употреба, но все още активни: разследвайте и отменете остатъчния достъп.
• Дублирани или преинсталирани: съгласувайте записите, без да губите историческите доказателства.
• Извън обхвата: документирайте причината и границата, която предотвратява относим достъп.

Знаменателят има значение. „98 % съответствие“ сред регистрираните устройства може да прикрие значителна неуправлявана съвкупност. Докладвайте покритието отделно от съответствието на конфигурацията и запазвайте датата на съгласуването и неизяснените записи.

Изградете базова линия, която може да бъде тествана

Базовата линия за крайни устройства трябва да превръща решенията за риска в настройки и критерии за проверка. Тя трябва да разграничава платформите и моделите на собственост, вместо да се преструва, че всяка настройка работи навсякъде.

Следното е практическа отправна точка, а не универсален законов или изискван от ISO контролен списък:

Определете какво означава „неизвестно“. Крайно устройство, което не е докладвало състоянието на криптирането, не е доказано криптирано. Третирайте липсващата или остаряла телеметрия като отделно състояние с ясна реакция, вместо да я превръщате в успешен резултат.

Прозорците за актуализации трябва да отразяват тежестта на уязвимостите, експозицията, наличните смекчаващи мерки и оперативните ограничения. Документирайте аварийната обработка на активно експлоатирани уязвимости и процес за актуализации, които нарушават работата на съществени приложения. Докладите от внедряването в MDM помагат да се установи състоянието на инсталацията; сами по себе си те не обясняват дали неотстраненият риск от уязвимости е приемлив.

При приложенията разграничавайте разпространението от контрола. Инсталирането на одобрено приложение не пречи на потребителите да инсталират алтернативи, освен ако платформата и конфигурацията не поддържат такова ограничение. Определете кой може да одобрява софтуер, какво изисква оценка и как се премахват остарелите или забранените приложения.

Всяко изключение от базовата линия се нуждае от отговорно лице, засегнати устройства, бизнес причина, оценка на риска, компенсиращи мерки, одобрение и срок на изтичане. Неподдържана операционна система с неограничен достъп до чувствителни данни не бива да остава безсрочно под обща бележка „бизнес изискване“.

Внедрявайте конфигурацията, без да бъркате възлагането с успеха

Използвайте пилотна група, която представя всяка важна платформа, режим на собственост и бизнес случай на употреба. Тествайте нормалната работа, пътуванията, поведението без връзка и възстановяването, а не само успешното регистриране на бюрото на администратора.

Преди широко внедряване установете предпоставките за управление: администраторски роли, права за регистриране, необходими сертификати или сервизни идентификационни данни и отговорност за подновяването им. Услугата за управление може да загуби ефективност, когато изтече сертификат, дори ако документите с политиките остават непроменени.

Проследявайте конфигурацията през отделни състояния: насочена, доставена, приложена, оценена и ефективна. Когато платформата показва по-малко етапи, документирайте това ограничение и добавете безопасен метод за проверка. Проверете конфликтните профили, остарелите агенти, неподдържаните настройки и действията на потребителите, които пречат на завършването.

Използвайте поетапно внедряване с одобрен път за връщане или възстановяване. Запишете версията на базовата линия, насочените групи, пилотните резултати, одобрението и неуспехите при внедряването. Екранна снимка на редактор на политики доказва предвидените настройки; докладите от устройствата и тестовете установяват дали тези настройки действително функционират.

Защитете и самата управляваща равнина. Използвайте поименни администраторски акаунти, подходящо силно удостоверяване, роли с най-малки привилегии и журналиране. Ограничете правата за масово изтриване и промяна на конфигурацията. Преглеждайте администраторите и сервизните идентификационни данни, защото компрометирането на услугата за управление може да засегне много крайни устройства едновременно.

Проверявайте криптирането и възстановяването поотделно

При лаптопите проверявайте внедрената защита на хранилището, а не само политика „активиране на криптиране“. При телефоните и таблетите разберете модела на криптиране на операционната система, поведението в заключено състояние и видимостта за управлението. Криптирането в покой и криптираният мрежов пренос са отделни твърдения.

Решете кое локално хранилище е обхванато, дали са разрешени преносими носители и как бизнес информацията може да напусне управляваните приложения. Защитеният системен диск не защитава автоматично експортиран файл на некриптиран външен диск.

Договореностите за възстановяване се нуждаят от собствен дизайн на контрола. Определете къде се съхранява материалът за възстановяване, кой може да го извлече, как извличането се разрешава и журналира и кога се изисква ротация или замяна. Не поставяйте тайните за възстановяване в общите одитни доказателства или в заявки към службата за поддръжка.

Тествайте възстановяването на определено тестово крайно устройство, като използвате одобрена процедура. Запазете разрешението и резултата, а не тайната. Поле в конзолата, показващо, че ключ съществува, не доказва, че упълномощените служители могат да възстановят устройството, когато е необходимо.

Защитата на мрежата зависи и от конфигурацията на приложенията и услугите. MDM може да разпространява сертификати или мрежови настройки, но не може да докаже, че всяко приложение използва подходящо конфигурирани криптирани връзки. За по-широкия жизнен цикъл вижте криптиране и управление на ключове.

Свържете състоянието на устройствата с решенията за достъп

Сигналът за съответствие има ограничена стойност, ако несъответстващите крайни устройства запазват неограничен достъп. Когато се поддържа, свържете информацията за доверието или съответствието на устройствата с контролите на достъпа на самоличностите и приложенията. Установете точно кои ресурси налагат условието и кои пътища за достъп го заобикалят.

Тествайте достъпа през браузър, нативните приложения, дистанционното администриране, остарялото удостоверяване и съществуващите сесии, когато е приложимо. Неуправляван браузър може да бъде блокиран, докато по-рано оторизиран клиент продължава да работи. Поведението при отмяна на сесии и актуалността на сигналите изискват изрично тестване.

Използвайте основани на риска ограничения. Чувствителните административни системи може да изискват по-строги условия за крайните устройства от ресурсите за сътрудничество с нисък риск. Определете процедури за авариен достъп и възстановяване, така че отказ на услугата за съответствие да не води до недокументирани постоянни заобикаляния.

Удостоверяването при отключване на устройството не е същото като удостоверяването в приложението. Заключването на екрана защитава оставено без надзор крайно устройство; многофакторното удостоверяване и оторизацията защитават достъпа до ресурси. MDM може да подпомогне конфигурацията, но доказателствата от доставчика на самоличности и приложенията трябва да обосноват тези отделни твърдения.

Подхождайте обмислено към личните устройства, загубата и напускането

За личните устройства решете дали управлението е на цялото устройство, на служебен профил, само на приложения или не е налично. Обяснете какво могат да виждат администраторите, какво могат да променят, каква бизнес информация се събира и какво може да бъде премахнато. Не приемайте, че проследяването на местоположението или видимостта на личните приложения са необходими или налични.

Когато телеметрията от устройствата на служителите включва лични данни, оценете приложимите задължения за защита на личните данни. ОРЗД изисква правно основание и спазване на относимите принципи на обработване; член 32 възприема основан на риска подход към сигурността, вместо да налага пълно криптиране при всички обстоятелства. Не бива да се приема, че съгласието на служителите е достатъчно. Осигурете подходящ преглед от гледна точка на защитата на личните данни и трудовото право за процедурите по наблюдение и премахване.

Разграничавайте селективното премахване на бизнес данни от пълното изтриване на устройството. Потвърдете поддържаното поведение за всеки режим на регистриране и го съобщете преди регистрирането. Премахването на служебен профил може да остави личните данни недокоснати, докато пълното изтриване има съществено различни последици.

При изгубено устройство реакцията трябва да идентифицира крайното устройство и потребителя, да оцени експозицията, да ограничи достъпа, да отмени съответните сесии или идентификационни данни, да изпрати поддържаните команди за заключване или изтриване и да запише резултатите. Дистанционното изтриване зависи от свързаността и възможностите на платформата. „Командата е поставена в опашка“ не означава „данните са премахнати“.

Процедурите при напускане трябва да обхващат както връщането на устройството, така и достъпа до информация. Отменяйте достъпа независимо от това дали устройството е върнато. Премахвайте бизнес профилите, когато е подходящо, запазвайте информацията, за която важат изисквания за съхранение, и извеждайте записите от инвентара едва след необходимите проверки. Тествайте тези процеси в безопасен обхват с тестови акаунти и устройства.

Запазвайте доказателства, които подкрепят ограничено твърдение

Пакетът с доказателства трябва да позволява на проверяващия да възстанови какво е било защитено през посочен период. Запазвайте датирани експорти, бройки на съвкупността, решения за изключения и записи за отстраняване. Включете достатъчно контекст, за да се разграничи оценка към определен момент от доказателства за текущо функциониране.

Полезни резултати са:

• Обхват и съгласуване на инвентара, включително неизяснените неуправлявани устройства.
• Одобрени версии на базовата линия и специфични за платформата настройки.
• Експорти на състоянието на устройствата, показващи идентификатори, регистриране, последен контакт и ефективна конфигурация.
• Одобрения на изключения със срокове на изтичане и компенсиращи мерки.
• Неуспехи при внедряването, заявки за отстраняване и проверка на приключването.
• Записи от тестове за възстановяване, отказ на достъп, изгубено устройство и напускане.
• Решения от периодичните прегледи и възложени последващи действия.

Документирайте филтрите на експорта, времето на събиране и тълкуването на полетата за статус. Защитете експортите по подходящ начин, защото те може да съдържат лични идентификатори или чувствителни подробности за инфраструктурата. Екранните снимки могат да обяснят конфигурацията, но експортите с възможност за търсене обикновено са по-полезни за анализ на съвкупността.

Правете извадки според риска и видовете неуспехи, а не само от изправни устройства. Включете различни платформи, скорошни регистрирания, привилегировани потребители, остарели крайни устройства и одобрени изключения. Текущ доклад не може да възстанови предишен период на преглед, освен ако историческите записи не са запазени.

Периодичните прегледи на покритието трябва да включват новодобавените устройства и променящите се модели на достъп. Полезни оперативни показатели са покритието на регистрирането, съответствието с оценената базова линия, остарялото докладване, изтеклите изключения и възрастта на отстраняванията. Определете всеки знаменател и праг. Непрекъснатото наблюдение на контролите дава допълнителен контекст за разграничаване на сигналите от прегледаните заключения.

Практически пример: преглед на смесен парк от устройства

Следващите числа и прагове са илюстративни допускания, а не отраслови сравнителни показатели.

Компания идентифицира 120 служебни лаптопа и 30 лични телефона, разрешени за служебна електронна поща. Нейната базова линия за лаптопите изисква регистриране, криптиране, поддържана операционна система, заключване на екрана и успешна оценка в рамките на седем дни. Личните телефони изискват управляван служебен профил и поддържан софтуер; управлението на цялото устройство е извън одобрената граница на поверителността.

Конзолата на MDM съдържа 116 лаптопа. От тях 108 отговарят на базовата линия, четири докладват просрочени актуализации, два имат остарели оценки и два показват неуспешно криптиране. Останалите четири лаптопа липсват в управлението.

Ако се докладва само резултатът от конзолата, се получават 108 от 116, или приблизително 93 % съответствие с базовата линия. Спрямо установената съвкупност от лаптопи 108 от 120, или 90 %, доказано отговарят на базовата линия. Покритието на регистрирането е приблизително 97 %. Това са различни показатели и нито един от тях не доказва контролите за личните телефони.

Записите за самоличностите показват, че два неуправлявани лаптопа са имали достъп до чувствително приложение. Екипът ограничава този достъп, разследва собствеността и регистрира устройствата. За другите два се потвърждава, че са изведени от употреба; доказателствата за отмяна на достъпа и бракуване подкрепят премахването им от активната съвкупност.

При телефоните трима потребители имат достъп до електронната поща без изисквания служебен профил. Достъпът им е ограничен, докато не бъде завършено регистрирането или одобрена алтернатива. Тестов телефон потвърждава, че селективното премахване изтрива служебния профил, без да изтрива личното съдържание.

Записът от прегледа запазва първоначалната съвкупност, промените от съгласуването, неуспехите, ограниченията на достъпа и провереното отстраняване. Той не заменя първоначалната неуспешна оценка с по-късна чиста екранна снимка.

Улеснете следващия преглед

Честите грешки са оперативни: броене само на регистрираните крайни устройства, доверие във възлагането на политики, приемане на остаряла телеметрия, оставяне на изключенията отворени и третиране на дистанционните команди като изпълнени действия. Всяка от тях може да бъде адресирана чрез определена съвкупност, изрично обработване на състоянията и датирана проверка.

Secani може да организира тази работа около съответните системи, изисквания, отговорни лица и доказателства. Качете документите с базовата линия, датираните експорти от MDM и записите от тестовете; свържете ги с контролите или решенията, които те подкрепят; и превърнете липсващите доказателства или неотстранените неуспехи във възложени задачи. Запазвайте човешкия преглед, одобрението и контекста на източника за съществените заключения. MDM остава оперативният инструмент за управление на крайни устройства; работното пространство за съответствие запазва контекста на внедряването и решенията от прегледите.

Практична следваща стъпка е да изберете едно чувствително приложение и да съгласувате всяко крайно устройство с достъп до него спрямо записите в управлението. Тествайте едно изправно, едно неуправлявано и едно остаряло крайно устройство. Запишете резултатите за достъпа и доказателствата за конфигурацията, след което възложете всяко необяснено несъответствие на отговорно лице. Това малко упражнение тества едновременно покритието, налагането и доказването.