Системите за видеонаблюдение често надживяват компаниите, които ги инсталират. В това интервю за Help Net Security, Роб Янсенс, директор по киберсигурност за регион EMEA в Hikvision Europe, обсъжда какво се случва, когато интеграторът вече го няма, документацията е загубена и никой не разполага с администраторските идентификационни данни.

Той обяснява защо продуктите трябва да позволяват на клиентите да възстановяват контрола самостоятелно и как настройките за сигурност по подразбиране (secure-by-default) намаляват щетите от предвидими грешки при инсталирането. Той също така разглежда ескроу споразуменията за изходен код, правилата за държава на произход и какви доказателства доставчиците могат и не могат да предложат на операторите на критична инфраструктура.

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

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

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

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

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

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

Тук е важна и разликата между сигурност по проект (secure-by-design) и сигурност по подразбиране (secure-by-default). Сигурност по проект означава, че сигурността се взема предвид по време на разработката, тестването и поддръжката. Сигурност по подразбиране означава, че клиентът не трябва да става специалист по сигурността, само за да получи разумно безопасна първоначална конфигурация.

Нашият жизнен цикъл за сигурна разработка (Security Development Lifecycle) обхваща продукта от изискванията и дизайна, през разработката, проверката, пускането на пазара и поддръжката. Това е правилната посока за индустрията. Сигурността не може да бъде нещо, което се добавя в края на проекта за инсталиране.

Разбира се, никой производител не може да компенсира всеки лош мрежов дизайн. Ако някой постави камера директно в публичния интернет, деактивира контролите и никога не отстранява уязвимости, все още съществува риск. Въпреки това, ние можем да направим продукта много по-устойчив на предвидими грешки.

Първо, бих искал да разбера точно какво е деактивирано и защо. Има легитимни оперативни изисквания за отдалечен достъп, но „работи“ не е същото като „сигурно е“.

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

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

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

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

Средата на заплахите се променя.