Подходы к организации информационной безопасности в корпоративных проектах

Подходы к организации информационной безопасности в корпоративных проектах

О компании…

• Часть 1. Бумажная безопасность
• Часть 2. Реальные инструменты информационной безопасности в проектах
• Часть 3. Работа внутри команды

Во-первых, этой статьей хотим осветить вопросы информационной безопасности на проектах. Почему? Потому что, подключаясь сейчас к какому-либо среднему или крупному проекту, легко обнаружить, что в команде со стороны заказчика появилась какая-нибудь служба защиты информации, или там этим занимается целый департамент безопасности. А там действительно присутствуют специалисты, которые начинают от вас требовать не просто «прийти и поставить 1С или настроить базу данных и что-то там запрограммировать», но ещё рассказать на их языке:

• что из себя представляет ваша информационная система с точки зрения информационной безопасности;
• какими мерами защиты вы закрываете те или иные угрозы в ней.

При анализе рынка часто встречаем ситуацию возникновения перегрузки по ресурсам при росте объемного показателя по проектам, поэтому предлагаем заниматься этим направлением активнее! И мы готовы помогать вам в этом.

Во-вторых, всегда нужно помнить про три главных вопроса, касающихся современной информационной безопасности на предприятиях:

1. Конфиденциальность – всё, что касается защиты информации от хищения, свободного неконтролируемого распространения, нерегламентированного её изменения;
2. Целостность – вопросы защиты от повреждения информации и её носителей (например, защита от повреждения базы данных) или вопросы срабатывания средств защиты в безопасном контуре;
3. Доступность информации – бэкапы, резервные копии, обеспечение бесперебойной работы 24/7.

Все эти аспекты важны при решении задачи в комплексе, не стоит забывать о них ни на одном этапе вашего проекта. А сейчас поговорим вот о чем.

Часть 1. Бумажная безопасность

«Бумажная безопасность» – уже устоявшийся термин в среде информационной безопасности. Это то, о чём мы говорим при построении каких-то конкурсных технических заданий, списков документов по проекту и так далее. 

Что нужно понимать, когда вы работаете с безопасностью с точки зрения бумаги? 

Во-первых, коллеги из службы информационной безопасности практически всегда оперируют термином «Автоматизированная Система», реже – «Информационная система».

Т.е. нужно понимать, в «Автоматизированную систему» включается всё! Не только то, что «напрограммировано» вами (или кем-то) в конфигурациях 1С, но и сама платформа 1С:Предприятие, операционные системы, всё прикладное обеспечение, которое установлено на этих операционных системах, средства виртуализации, железо. И не стоит забывать про персонал, который всё это обслуживает!

Поэтому, когда вы входите в проект и видите требования о разработке «автоматизированной системы», и к ней есть какие-то требования информационной безопасности – ВНИМАНИЕ! даже если это не описано напрямую, – будьте готовы к тому, что вам придётся писать всю документацию по ГОСТ.  Будьте готовы, что вам придётся описывать это формально, согласно всем требуемым методикам и правилам, принятым на предприятии, и по ГОСТ.

Во-вторых, важно понимать, что история с КИИ (Критической Информационной Инфраструктурой – 187-ФЗ) сейчас активно развивается. Маховик набирает обороты, и теперь уже не только ОПК попадает под пристальное внимание, но и операторы связи, и ключевые государственные информационные системы, и телекоммуникации в целом – список огромный!

Поэтому, когда начинаете работать с заказчиком, ВСЕГДА на всякий случай уточняйте, попадает он под действие 187-ФЗ или нет. И если попадает – будьте уверены, вас обязательно попросят (даже если это не отражено в контракте явно) подготовить какие-то классификации и документы по этой системе. Лучше погрузиться в эти вопросы на входе, чем позже в авральном порядке пытаться выполнить требования заказчика.

На картинке ниже представлена примерная таблица списка документов, их объема и обязательности наличия в комплекте по проекту с участием КИИ:

Каждый из обязательных документов требует внимательного к себе отношения. 

Например, по «Модели угроз безопасности» мы сталкиваемся с частой ситуацией у обратившихся к нам партнеров: «Мы нечаянно выиграли конкурс, а в нём было требование по разработке модели угроз и нам сказали – ищите субподрядчика с лицензией». Но проблема в том, что это не помогает – потому что лицензия должна быть у того, кто выигрывает генеральный подряд. И в итоге с заказчиком начинаются сложности. Обращайте на эти нюансы внимание, пожалуйста.

Кратко по документам из списка выше:

• «Модель угроз безопасности» – документ описывает, ОТ ЧЕГО мы защищаем систему. Определяет, какие угрозы могут возникнуть. Например, «угроза хищения данных». Есть методика от ФСТЭК, как оформлять этот документ.
• «Модель нарушителя» – документ описывает, ОТ КОГО мы защищаем систему.
• «Акт определения уровня защищенности» – вы готовите проект, а вводит его у себя непосредственно заказчик. Таких актов может быть несколько
• «ТЗ на системы защиты» – это в том числе описание того, КАК вы будете защищать свою систему. Например, антивирусом, средствами контроля привилегированного доступа, защищённой операционной системой, как вы будете решать задачу защиты на уровне виртуализации и так далее.  Иногда у заказчика есть базовые документы на его основную систему – нужно обязательно сделать отсылку к ним. Но в последнее время требуют всё прописывать явно.
• «Технический проект на системы защиты» – в ТЗ пишется в формате «должно удовлетворять», здесь в формате «удовлетворяется с помощью 1, 2, 3, …». 
• «Регламент учета, хранения и уничтожения …» – например, что делать с flash-картами.
• «Регламент резервного копирования» – тут всё понятно, но помните, что его нужно оформить с точки зрения информационной безопасности. В 90% случаев на проектах изначально не пишут этот документ, А ЗРЯ a86;
• «Матрица доступа к ресурсам» – просто, но нужно заполнить внимательно!

В итоге получаем порядка 1000 страниц документации, которая обязательно нужна.

Где мы можем для себя использовать историю с бумажной безопасностью? 

Во-первых, разделяйте понятие аттестация и сертификация. 

Сертифицируются средства защиты информации, то есть программный продукт. 

Аттестуется ваша система, то есть то что вы сделали, написали программный код и т.п.

Во-вторых, с точки зрения решений на платформе 1С следует помнить следующее: бытует мнение, что 8.3.17z идентична 8.3.17. Это не так! Вернее, обычно это так, но есть нюансы, связанные с техническими условиями использования платформы.

Поясняем: ЗПК (защищенный программный комплекс) 1С:Предприятие 8 (платформа 1С) нужен прежде всего для выполнения требований регуляторов при работе с персональными данными. Основные варианты применения: государственные информационные системы до 1 класса включительно, информационные системы персональных данных всех уровней защищенности.

ЗПК может (и должен) применяться:

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

В платформе 1С реализованы следующие доработки для соблюдения требований по информационной безопасности:

1. Регистрация аутентификации и отказа в аутентификации.
2. Регистрация изменений прав пользователей позволяет определить, когда какие роли назначались пользователю.
3. Регистрация фактов отказа в доступе. Регистрируются все факты отказа в доступе пользователю. Например, для поиска массовых попыток обращения к недоступным для пользователя ресурсам.
4. Регистрация доступа к защищаемым ресурсам:

• разработчик включает регистрацию для доступа к определенным полям по определенным объектам метаданных;
• разработчик описывает какую ключевую информацию необходимо включать в события журнала регистрации для поиска событий;
• система реализует отражение всех фактов доступа к указанной информации (например, сотрудника, к данным которого выполнялось обращение);
• система предоставляет возможность отбора зарегистрированных событий по метаданным и данным. Например, поиск всех обращений к защищаемым данным по конкретному физическому лицу и т.д.

Кроме того, к информационным системам компании-заказчики могут предъявлять дополнительные требования. Например, ограничение доступа в интернет, требования к установленному на рабочих местах программному обеспечению, антивирусам, операционным системам, политикам безопасности и т.д. Эти требования выполняются комплексно - как с использованием наложенных средств защиты, так и с применением защищенной версии платформы 1С:Предприятия 8, и в идеале оба подхода должны использоваться совместно.

Аттестация – лицензируемый вид деятельности! Если нет лицензии – не занимайтесь этими вопросами. Даже если впрямую это нигде не упоминается.

Деятельность по работе в области информационной безопасности имеет ряд ограничений и лицензий. Лицензия ФСТЭК (ТЗКИ):

• защита конфиденциальных данных от возможных утечек посредством технических объектов (АС, помещений с размещенными АС, переговорных — защищаемых помещений);
• защита конфиденциальных данных от НСД (несанкционированного доступа) и их искажения в АС;
• отслеживание защищенности конфиденциальных данных АС и отдельных модулей;
• аттестации с проведением испытаний по требованиям информационной защиты (АС, рабочих площадей, переговорных);
• проектирование защищенных АС, самостоятельных модулей; 
• защита рабочих площадей с подключенными АС, переговорных;
• установка, наладка, испытания и ремонт технических/программных средств информационной защиты и контроля.

Лайфхак! Если у вас есть лицензия ФСТЭК (ТЗКИ), то Z-платформа от 1С ЯВЛЯЕТСЯ средством информационной защиты программы. Её установка, настройка на серверах заказчика – лицензируемый вид деятельности. Пункт, которым часто можно защищать свои конкурсы! ( мы, конечно, ни на что не намекаем  ;) )

Часть 2. Реальные инструменты информационной безопасности в проектах

Здесь рассмотрим реальные задачи информационной безопасности (ИБ) и способы их решения на проектах, с которыми сталкивались сами и которые неоднократно решали.

Во-первых – применение платформы 1С:Предприятие 8z. Ко всему сказанному выше добавляем рекомендацию хорошенько изучить формуляры и ТУ, помнить про ограничения. 

Например, рано или поздно вы с заказчиком (его службой ИБ) приходите к вопросу «а где у вас контролируется ролевая модель и как вы контролируете, что такой-то пользователь имеет доступ к таким-то данным», вы отвечаете «в платформе» – следовательно это СЗИ «принесите, пожалуйста, на это сертификат».

Во-вторых, практически на каждом проекте – вопросы внешних провайдеров аутентификации. Например, технология OpenID. Или двухфакторная аутентификация, которая требует подключения SMS-шлюза. Часто в защищенных контурах этого всего нет и приходится интегрироваться с уже существующей допущенной туда системой.

В-третьих, работа с назначением прав. По нашему опыту, 90% решений на 1С управляют правами так: завел пользователя, поставил галочки по существующим в прикладном решении 1С ролям и всё. С точки зрения ИБ заказчика этого может быть недостаточно! 

На массу вопросов ИБ: «А почему такие, кто согласовал выдачу этих прав, какой у них период действия, когда они должны быть отозваны, временные они или не временные, …». Ответов чаще всего сходу нет. Поэтому от ИБ заказчика вы получите требование либо интегрироваться с уже существующей у них IDM-системой, либо разрабатывать аналог внутри разворачиваемой системы.

В-четвертых, логирование событий безопасности. Формально это требование закрывается средствами Журнала регистрации платформы 1С:Предприятие 8 + некоторыми событиями, которые можно взять из Технологического журнала (например, подключения к консоли кластера). 

Но чаще просят экспортировать эти записи из форматов 1С во внешние информационные системы, типа Elastic – с точки зрения удобства и скорости последующего анализа службами ИБ. Будьте к этому готовы. Либо, как вариант, это снова придется разрабатывать внутри внедряемой системы – под запросы ИБ заказчика. 

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

В-пятых, на крупных проектах рано или поздно вы придете к некоему «АРМ сотрудника ИБ», где специалист сможет просматривать заявки своего типа, изучать необходимые протоколы и проводить расследования.

Сейчас мы на многих проектах, особенно территориально распределенных, где рабочих мест очень много (несколько тысяч или десятки тысяч), сталкиваемся с идеей контроля защищенности рабочих мест. На основании анализа требований заказчиков даже написали свой продукт – «САКУРА».

Когда вы запускаете систему, всё что находится в серверной, включая межсетевой экран – это внутренний контур. Тогда все рабочие места с этой точки зрения становятся внешними и получают требования ИБ по уровню защищенности (например, должен быть установлен антивирус). Иногда к ним возникают требования по аттестации. В этом случае ИБ задает ожидаемый вопрос: «Как будет осуществляться контроль всего этого?». По большому счёту есть два варианта развития событий:

1. Скорее всего вы ответите, что будете организационными мерами это осуществлять. 50/50 что это удовлетворит ИБ.
2. В случае, если ответ в п.1 ИБ не убедил – смотрите решения по контролю защищенности рабочих мест класса нашего комплекса САКУРА.

Далее – вопросы, связанные с интеграцией. Особенно важно это для тех, кто попадает под 187-ФЗ, подключен к «ГосСОПКА», есть особые требования по интеграции и ИБ заказчика. Например, поставлена явно задача контроля управления и контроля инцидентами ИБ типа SIEM. Или нужно установить и запустить анализаторы логов, контроля целостности, плюс со всем с этим нужно будет интегрироваться. 

Даже если это не написано в техническом задании, либо описано кратко и мелкими буквами – это может вылиться в довольно объемные (неожиданные) работы. 

И не стоит забывать про идею «безопасной разработки». Внедряйте системы контроля качества кода. Начните хотя бы с систем статического анализа – например, «SonarQube». ИБ нужно видеть, кто разрабатывает, соответствует ли это стандартам, есть ли логи, журналы помещений того или иного кода в хранилище и тому подобное. 

Крайне желательно иметь хотя бы в минимальном наборе механизмы DevOps, проверки безопасности.

Часть 3. Работа внутри команды

Работая с заказчиком, у которого сильные требования по ИБ, следует помнить, что вы тоже попадаете под наблюдение. Инструктируйте всех, кто работает в вашей команде с заказчиком и проводите регулярные тренинги по информационной безопасности!

Всегда выясняйте и учитывайте требования и организационные меры по ИБ конкретного заказчика. 

Контролируйте каналы передачи информации:

• Мессенджеры (WhatsApp / Telegram / Skype / …)
• Социальные сети, открытые форумы, доски объявлений, «чатики»
• Электронная почта
• Мобильная связь

Сейчас необходимая информация легко достаётся, когда знаешь где брать. 

Будучи руководителем проекта, либо руководителем компании, помните – в случае инцидента по ИБ за своего сотрудника придется отвечать.  Поэтому работайте со своими сотрудниками, объясняя им азы безопасности. Это действительно важно, хотя кажется очевидным. 

Утечки могут происходить в совершенно неожиданные моменты. Например, был у нас реальный случай, когда тортик на дне рождения в офисе был подан на распечатке бюджета одного из предприятий a86;

На что в первую очередь нужно обратить внимание при инструктаже персонала:

1. Запрещается передача логинов и паролей. В первую очередь, между коллегами. Т.е. когда условный Вася дал свои данные «погонять» условному Пете. Если Пете нужен куда-либо доступ – оформите его официально. Помните – за все действия под конкретным логином отвечает владелец логина.
2. Предотвращайте утечки информации. Выгрузки баз, какие-то документы заказчика в электронном и/или бумажном виде. Такие утечки могут довести до уголовного преследования в том числе. Например, у заказчика сервер «тормозит», решили быстро базу скопировать, чтобы разобраться у себя «по-быстрому» с проблемой.
3. Конфиденциальность данных – не разглашайте в общественных местах, соцсетях. Не теряйте документы. Не пересылайте их по незащищенным каналам связи (например, общедоступные мессенджеры, электронная почта).
4. Вообще, ИБ внимательно следит за активностью в соцсетях – следите за этим постоянно, пожалуйста.
5. Качество разработки, аккуратность поведения в постороннем контуре. Не допускайте несознательного (тем более – сознательного) вредительства. «Ой, я нечаянно удалил журнал регистрации 1С за год» или «Удалил, место чтоб почистить» и таких примеров сотни. Не надо самодеятельности. Если нужно что-то удалить – обращайтесь к представителю заказчика по установленным у него регламентам.

И обязательно (повторимся) проводите тренинги и «учебные тревоги» среди сотрудников. Без тренировки теоретическая информация и «страшилки» быстро выветриваются из голов.

В завершение статьи приведем пример такого тренинга из реальной жизни: «Учебная атака».

И это в проекте, где присутствуют регулярные тренинги и инструктажи по информационной безопасности.

Если нет времени или квалификации проводить тренинги по ИБ самостоятельно – отправьте сотрудников на курсы. Есть платные, есть бесплатные. У нас неплохой уровень консалтинга по ИБ, например – обращайтесь, договоримся!

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