Сижу, никого не трогаю. Системы и сервисы по методу «херак-херак и в продакшен» внедряю… и тут менеджмент захотел безопасность. Куда бежать?

Вариант 1 – нанимаем професиональных «ИБшников». В штат или как внешний консалт нужно рассматривать отдельно, т.к. оба варианта со своими плюсами и минусами. Но в любом случае, как нормальный штатный ИБшник – так и консалтеры не будут все в вашей инфраструктуре делать ручками сами. Они аргументировано нарисуют экшен план «что делать ИТишникам компании».

Вариант 2 – ИТишники компании могут сделать что-то самостоятельно. Но с чего начать ? На рынке куча продавцов решений безопасности, готовые вам что-то продать, интегрировать, настроить и поддерживать. В интернете куча инфы как настроить безопасность домена, как повысить безопасность сервера почты, как из говна и палок прибить проксю… Все это класно, но такая безопасность не будет комплексной. Это просто закроет пару дырок.

Хорошо. Есть – же целые стандарты ИБ, говорящие как пострить эту комплексную безопасность. ISO 27000, NIST, PCI DSS (бумажно-бюрократическую КСЗИ в расчет не берем)…

–   ISO 27000 – риск-ориентированый подход. Требует большой вовлеченности всех команд компании, долог в имплементации, небольшим компаниям просто нецелесообразен. По моему мнению, нереально внедрить без помощи професиональных ИБшников.

–   NIST – мега круто. По низким уровням зрелости возможен для внедрения но не обеспечит безопасности. По высоким уровням – безумно дорог. Опять таки для небольших компаний нецелесообразен. Без професиональных ИБшников делать нечего.

–   PCI DSS – слишком специфичен.

Что же делать? Где найти нормальный гайд по построению базовой безопасности без запредельной стоимости, без необходимости иметь 30-лет опыта в ИБ? Какая область в стране имеет адекватную безопасность? Госорганы с КСЗИ опять в расчеты не берем… А есть же Банки. Они реально переживают за безопасность. И у них есть нормативка от Нацбанка. И есть среди этой нормативки Положення про організацію заходів із забезпечення інформаційної безпеки в банківській системі України  от 28.09.2017 № 95.

Постановление родилось после NotPetya атаки, и кроме организационных моментов, необходимости строить систему безопасности по ISO 27000, кучи требований по использованию локальных криптоалгоритмов имеет то, что мы можем использовать для построения базового уровня безопасности. Если посмотреть на требования документа, найдем простые наборы минимальных требований. Примеры:

Антивирус:

– антивирус должен быть (разговоры о том, что он безтолку жрет ресурсы – нахрен);

– антивирус должен быть везде. Даже на линухе и на компах не имеющих доступа в интернет. Даже на компе директора и самого сис-админа;

– антивирус должен централизовано управляться;

– антивирус должен регулярно и везде обновляться;

– любой внешний носитель – подключаемый в компании должен сначала провериться антивирусом;

– все должно переодически пересканироваться.

Права пользователей:

– Пользователям необходимо дать «минимально-достаточные права». Не должны иметь учетки рядовых пользователей админские права. Нигде.

– У админов должно быть по  две учетки: отдельно для «проверить почту и пошариться в инете», отдельно для администрирования.

– Если учетка не используется – должна блокироваться.

– Права учеток нужно периодически пересматривать.

Сегментация сети:

– ДМЗ , пользователи, сервера приложений, сервера баз данных – для всего отдельные сегменты.

– Доступ на сервера приложений из пользовательского сегмента открыть (разумеется только по портам этих приложений).

– Доступа на базы – только с серверов приложений.

– Все что смотрит в интернет – в ДМЗ.

– Админить сервера надо через джамп-сервер. Подключаться на джамп под юзерской учеткой, а с него на целевой сервер под админской.

И так по большинству направлений. Дальше – гугл в помощь.  Изучаем от чего та или иная мера спасает и как ее внедрить (ок, гугл, что такое ДМЗ и как его построить).

В документе есть требования не только технического, а и организационного характера. К ним тоже надо присмотреться. Например требования иметь ответственного за ИБ со стороны высшего менеджмента. Во-первых, такой менеджер должен потдерживать вас ресурсами. Во-вторых, он, своим авторитетом, должен разрулить ваш конфликт с «вечно занятыми работой» сотрудниками, которым «нехороший админ» закрыл доступ к флешкам, отобрал права админа, закрыл доступ к фейсбуку… Теперь бедняжка не может ни музычку на флешке принести (херня что вместе с музыкой куча вирусни приходит), ни амиго-браузер поставить… А менеджер должен объяснить, что это необходимо для безопасности, которую админ строит именно по задаче менеджмента. Если менеджмент не готов потдерживать вас ни ресурсами, ни авторитетом – безопасность вы не построите никак. Без поддержки менеджмента это нереально.

Вывод: Если ищете гайд как построить базовую безопасность своей инфраструктуры, поглядите на Положення НБУ про організацію заходів із забезпечення інформаційної безпеки в банківській системі України от 28.09.2017 № 95. Постройте фундамент, а дальше или развивайте сами, или приглашайте професионалов 🙂

Чего нет в документе – это «обучения персонала». Эта задача крайне важна как для ИТ, так и для безопасности. Но эту тему попробуем разрулить в следующей статье 😉