Подходы к организации информационной безопасности в корпоративных проектах
- Часть 1. Бумажная безопасность
- Часть 2. Реальные инструменты информационной безопасности в проектах
- Часть 3. Работа внутри команды
Во-первых, этой статьей хотим осветить вопросы информационной безопасности на проектах. Почему? Потому что, подключаясь сейчас к какому-либо среднему или крупному проекту, легко обнаружить, что в команде со стороны заказчика появилась какая-нибудь служба защиты информации, или там этим занимается целый департамент безопасности. А там действительно присутствуют специалисты, которые начинают от вас требовать не просто «прийти и поставить 1С или настроить базу данных и что-то там запрограммировать», но ещё рассказать на их языке:
- что из себя представляет ваша информационная система с точки зрения информационной безопасности;
- какими мерами защиты вы закрываете те или иные угрозы в ней.
Проекты растут, требования к ним ужесточаются. В каждом проекте появляется служба Информационной Безопасности со своими требованиями, которые необходимо учитывать с самого начала.
При анализе рынка часто встречаем ситуацию возникновения перегрузки по ресурсам при росте объемного показателя по проектам, поэтому предлагаем заниматься этим направлением активнее! И мы готовы помогать вам в этом.
Во-вторых, всегда нужно помнить про три главных вопроса, касающихся современной информационной безопасности на предприятиях:
- Конфиденциальность – всё, что касается защиты информации от хищения, свободного неконтролируемого распространения, нерегламентированного её изменения;
- Целостность – вопросы защиты от повреждения информации и её носителей (например, защита от повреждения базы данных) или вопросы срабатывания средств защиты в безопасном контуре;
- Доступность информации – бэкапы, резервные копии, обеспечение бесперебойной работы 24/7.
Все эти аспекты важны при решении задачи в комплексе, не стоит забывать о них ни на одном этапе вашего проекта. А сейчас поговорим вот о чем.
Часть 1. Бумажная безопасность
«Бумажная безопасность» – уже устоявшийся термин в среде информационной безопасности. Это то, о чём мы говорим при построении каких-то конкурсных технических заданий, списков документов по проекту и так далее.
Что нужно понимать, когда вы работаете с безопасностью с точки зрения бумаги?
Во-первых, коллеги из службы информационной безопасности практически всегда оперируют термином «Автоматизированная Система», реже – «Информационная система».
Автоматизированная Система – система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций (ГОСТ 34).
Внимание: не только 1С! (но и ОС, СУБД, серверы и прочее)
Определяющие законы:
- 152-ФЗ – персональные данные
- 98-ФЗ – коммерческая тайна
- 63-ФЗ – электронная подпись
- 5485-1 – государственная тайна
- 187-ФЗ – Критическая Информационная Инфраструктура
Наш регулятор – ФСТЭК
Т.е. нужно понимать, в «Автоматизированную систему» включается всё! Не только то, что «напрограммировано» вами (или кем-то) в конфигурациях 1С, но и сама платформа 1С:Предприятие, операционные системы, всё прикладное обеспечение, которое установлено на этих операционных системах, средства виртуализации, железо. И не стоит забывать про персонал, который всё это обслуживает!
Поэтому, когда вы входите в проект и видите требования о разработке «автоматизированной системы», и к ней есть какие-то требования информационной безопасности – ВНИМАНИЕ! даже если это не описано напрямую, – будьте готовы к тому, что вам придётся писать всю документацию по ГОСТ. Будьте готовы, что вам придётся описывать это формально, согласно всем требуемым методикам и правилам, принятым на предприятии, и по ГОСТ.
Во-вторых, важно понимать, что история с КИИ (Критической Информационной Инфраструктурой – 187-ФЗ) сейчас активно развивается. Маховик набирает обороты, и теперь уже не только ОПК попадает под пристальное внимание, но и операторы связи, и ключевые государственные информационные системы, и телекоммуникации в целом – список огромный!
Поэтому, когда начинаете работать с заказчиком, ВСЕГДА на всякий случай уточняйте, попадает он под действие 187-ФЗ или нет. И если попадает – будьте уверены, вас обязательно попросят (даже если это не отражено в контракте явно) подготовить какие-то классификации и документы по этой системе. Лучше погрузиться в эти вопросы на входе, чем позже в авральном порядке пытаться выполнить требования заказчика.
На картинке ниже представлена примерная таблица списка документов, их объема и обязательности наличия в комплекте по проекту с участием КИИ:
Каждый из обязательных документов требует внимательного к себе отношения.
Например, по «Модели угроз безопасности» мы сталкиваемся с частой ситуацией у обратившихся к нам партнеров: «Мы нечаянно выиграли конкурс, а в нём было требование по разработке модели угроз и нам сказали – ищите субподрядчика с лицензией». Но проблема в том, что это не помогает – потому что лицензия должна быть у того, кто выигрывает генеральный подряд. И в итоге с заказчиком начинаются сложности. Обращайте на эти нюансы внимание, пожалуйста.
Кратко по документам из списка выше:
- «Модель угроз безопасности» – документ описывает, ОТ ЧЕГО мы защищаем систему. Определяет, какие угрозы могут возникнуть. Например, «угроза хищения данных». Есть методика от ФСТЭК, как оформлять этот документ.
- «Модель нарушителя» – документ описывает, ОТ КОГО мы защищаем систему.
- «Акт определения уровня защищенности» – вы готовите проект, а вводит его у себя непосредственно заказчик. Таких актов может быть несколько
- «ТЗ на системы защиты» – это в том числе описание того, КАК вы будете защищать свою систему. Например, антивирусом, средствами контроля привилегированного доступа, защищённой операционной системой, как вы будете решать задачу защиты на уровне виртуализации и так далее. Иногда у заказчика есть базовые документы на его основную систему – нужно обязательно сделать отсылку к ним. Но в последнее время требуют всё прописывать явно.
- «Технический проект на системы защиты» – в ТЗ пишется в формате «должно удовлетворять», здесь в формате «удовлетворяется с помощью 1, 2, 3, …».
- «Регламент учета, хранения и уничтожения …» – например, что делать с flash-картами.
- «Регламент резервного копирования» – тут всё понятно, но помните, что его нужно оформить с точки зрения информационной безопасности. В 90% случаев на проектах изначально не пишут этот документ, А ЗРЯ a86;
- «Матрица доступа к ресурсам» – просто, но нужно заполнить внимательно!
В итоге получаем порядка 1000 страниц документации, которая обязательно нужна.
Где мы можем для себя использовать историю с бумажной безопасностью?
Во-первых, разделяйте понятие аттестация и сертификация.
Сертифицируются средства защиты информации, то есть программный продукт.
Аттестуется ваша система, то есть то что вы сделали, написали программный код и т.п.
Система, которую мы внедряем, чаще всего должна быть аттестована.
Аттестация системы защиты персональных данных – это комплекс организационно-технических мероприятий, который призван оценить эффективность принимаемых мер защиты и их соответствие требованиям нормативных документов РФ в области защиты ПДн. Лицензируемый вид деятельности!
Средства защиты информации, которые мы применяем в системе должны быть сертифицированы!
У 1С есть специализированные версии платформы (на момент написания статьи):
Z-версия (Конфиденциальные данные, ПДн), версия платформы 8.3.17
S-версия (Секретно, Совершенно секретно), версия платформы 8.3.13
Во-вторых, с точки зрения решений на платформе 1С следует помнить следующее: бытует мнение, что 8.3.17z идентична 8.3.17. Это не так! Вернее, обычно это так, но есть нюансы, связанные с техническими условиями использования платформы.
Поясняем: ЗПК (защищенный программный комплекс) 1С:Предприятие 8 (платформа 1С) нужен прежде всего для выполнения требований регуляторов при работе с персональными данными. Основные варианты применения: государственные информационные системы до 1 класса включительно, информационные системы персональных данных всех уровней защищенности.
ЗПК может (и должен) применяться:
- в организациях, являющихся оператором персональных данных (практически все организации на данный момент),
- в организациях, оказывающих услуги по ведению ИСПДн нескольких операторов,
- в организациях, работающих с государственными информационными системами.
В платформе 1С реализованы следующие доработки для соблюдения требований по информационной безопасности:
- Регистрация аутентификации и отказа в аутентификации.
- Регистрация изменений прав пользователей позволяет определить, когда какие роли назначались пользователю.
- Регистрация фактов отказа в доступе. Регистрируются все факты отказа в доступе пользователю. Например, для поиска массовых попыток обращения к недоступным для пользователя ресурсам.
- Регистрация доступа к защищаемым ресурсам:
- разработчик включает регистрацию для доступа к определенным полям по определенным объектам метаданных;
- разработчик описывает какую ключевую информацию необходимо включать в события журнала регистрации для поиска событий;
- система реализует отражение всех фактов доступа к указанной информации (например, сотрудника, к данным которого выполнялось обращение);
- система предоставляет возможность отбора зарегистрированных событий по метаданным и данным. Например, поиск всех обращений к защищаемым данным по конкретному физическому лицу и т.д.
Кроме того, к информационным системам компании-заказчики могут предъявлять дополнительные требования. Например, ограничение доступа в интернет, требования к установленному на рабочих местах программному обеспечению, антивирусам, операционным системам, политикам безопасности и т.д. Эти требования выполняются комплексно - как с использованием наложенных средств защиты, так и с применением защищенной версии платформы 1С:Предприятия 8, и в идеале оба подхода должны использоваться совместно.
Аттестация – лицензируемый вид деятельности! Если нет лицензии – не занимайтесь этими вопросами. Даже если впрямую это нигде не упоминается.
Деятельность по работе в области информационной безопасности имеет ряд ограничений и лицензий. Лицензия ФСТЭК (ТЗКИ):
- защита конфиденциальных данных от возможных утечек посредством технических объектов (АС, помещений с размещенными АС, переговорных — защищаемых помещений);
- защита конфиденциальных данных от НСД (несанкционированного доступа) и их искажения в АС;
- отслеживание защищенности конфиденциальных данных АС и отдельных модулей;
- аттестации с проведением испытаний по требованиям информационной защиты (АС, рабочих площадей, переговорных);
- проектирование защищенных АС, самостоятельных модулей;
- защита рабочих площадей с подключенными АС, переговорных;
- установка, наладка, испытания и ремонт технических/программных средств информационной защиты и контроля.
Лайфхак! Если у вас есть лицензия ФСТЭК (ТЗКИ), то Z-платформа от 1С ЯВЛЯЕТСЯ средством информационной защиты программы. Её установка, настройка на серверах заказчика – лицензируемый вид деятельности. Пункт, которым часто можно защищать свои конкурсы! ( мы, конечно, ни на что не намекаем ;) )
Установил Z-платформу 1С – нужна лицензия ФСТЭК!
(иногда = способ защиты в конкурсе)
Часть 2. Реальные инструменты информационной безопасности в проектах
Здесь рассмотрим реальные задачи информационной безопасности (ИБ) и способы их решения на проектах, с которыми сталкивались сами и которые неоднократно решали.
Во-первых – применение платформы 1С:Предприятие 8z. Ко всему сказанному выше добавляем рекомендацию хорошенько изучить формуляры и ТУ, помнить про ограничения.
Например, рано или поздно вы с заказчиком (его службой ИБ) приходите к вопросу «а где у вас контролируется ролевая модель и как вы контролируете, что такой-то пользователь имеет доступ к таким-то данным», вы отвечаете «в платформе» – следовательно это СЗИ «принесите, пожалуйста, на это сертификат».
Во-вторых, практически на каждом проекте – вопросы внешних провайдеров аутентификации. Например, технология OpenID. Или двухфакторная аутентификация, которая требует подключения SMS-шлюза. Часто в защищенных контурах этого всего нет и приходится интегрироваться с уже существующей допущенной туда системой.
В-третьих, работа с назначением прав. По нашему опыту, 90% решений на 1С управляют правами так: завел пользователя, поставил галочки по существующим в прикладном решении 1С ролям и всё. С точки зрения ИБ заказчика этого может быть недостаточно!
На массу вопросов ИБ: «А почему такие, кто согласовал выдачу этих прав, какой у них период действия, когда они должны быть отозваны, временные они или не временные, …». Ответов чаще всего сходу нет. Поэтому от ИБ заказчика вы получите требование либо интегрироваться с уже существующей у них IDM-системой, либо разрабатывать аналог внутри разворачиваемой системы.
В-четвертых, логирование событий безопасности. Формально это требование закрывается средствами Журнала регистрации платформы 1С:Предприятие 8 + некоторыми событиями, которые можно взять из Технологического журнала (например, подключения к консоли кластера).
Но чаще просят экспортировать эти записи из форматов 1С во внешние информационные системы, типа Elastic – с точки зрения удобства и скорости последующего анализа службами ИБ. Будьте к этому готовы. Либо, как вариант, это снова придется разрабатывать внутри внедряемой системы – под запросы ИБ заказчика.
На одном из проектов по просьбе заказчика мы завели специальный регистр сведений, куда записывали протокол работы каждого пользователя в требуемом ИБ формате – например, фиксировали открытие формы платежки, даже если данные в базе оставались неизменными.
В-пятых, на крупных проектах рано или поздно вы придете к некоему «АРМ сотрудника ИБ», где специалист сможет просматривать заявки своего типа, изучать необходимые протоколы и проводить расследования.
Сейчас мы на многих проектах, особенно территориально распределенных, где рабочих мест очень много (несколько тысяч или десятки тысяч), сталкиваемся с идеей контроля защищенности рабочих мест. На основании анализа требований заказчиков даже написали свой продукт – «САКУРА».
Когда вы запускаете систему, всё что находится в серверной, включая межсетевой экран – это внутренний контур. Тогда все рабочие места с этой точки зрения становятся внешними и получают требования ИБ по уровню защищенности (например, должен быть установлен антивирус). Иногда к ним возникают требования по аттестации. В этом случае ИБ задает ожидаемый вопрос: «Как будет осуществляться контроль всего этого?». По большому счёту есть два варианта развития событий:
- Скорее всего вы ответите, что будете организационными мерами это осуществлять. 50/50 что это удовлетворит ИБ.
- В случае, если ответ в п.1 ИБ не убедил – смотрите решения по контролю защищенности рабочих мест класса нашего комплекса САКУРА.
Далее – вопросы, связанные с интеграцией. Особенно важно это для тех, кто попадает под 187-ФЗ, подключен к «ГосСОПКА», есть особые требования по интеграции и ИБ заказчика. Например, поставлена явно задача контроля управления и контроля инцидентами ИБ типа SIEM. Или нужно установить и запустить анализаторы логов, контроля целостности, плюс со всем с этим нужно будет интегрироваться.
Даже если это не написано в техническом задании, либо описано кратко и мелкими буквами – это может вылиться в довольно объемные (неожиданные) работы.
И не стоит забывать про идею «безопасной разработки». Внедряйте системы контроля качества кода. Начните хотя бы с систем статического анализа – например, «SonarQube». ИБ нужно видеть, кто разрабатывает, соответствует ли это стандартам, есть ли логи, журналы помещений того или иного кода в хранилище и тому подобное.
Крайне желательно иметь хотя бы в минимальном наборе механизмы DevOps, проверки безопасности.
Часть 3. Работа внутри команды
Работая с заказчиком, у которого сильные требования по ИБ, следует помнить, что вы тоже попадаете под наблюдение. Инструктируйте всех, кто работает в вашей команде с заказчиком и проводите регулярные тренинги по информационной безопасности!
Всегда выясняйте и учитывайте требования и организационные меры по ИБ конкретного заказчика.
Предполагайте, что всё что вы говорите и делаете – известно!
Например, ваша работа на сервере может быть записана службой ИБ (видео действий пользователя, журналы выполненных действий и команд)
Контролируйте каналы передачи информации:
- Мессенджеры (WhatsApp / Telegram / Skype / …)
- Социальные сети, открытые форумы, доски объявлений, «чатики»
- Электронная почта
- Мобильная связь
Сейчас необходимая информация легко достаётся, когда знаешь где брать.
Будучи руководителем проекта, либо руководителем компании, помните – в случае инцидента по ИБ за своего сотрудника придется отвечать. Поэтому работайте со своими сотрудниками, объясняя им азы безопасности. Это действительно важно, хотя кажется очевидным.
Утечки могут происходить в совершенно неожиданные моменты. Например, был у нас реальный случай, когда тортик на дне рождения в офисе был подан на распечатке бюджета одного из предприятий a86;
На что в первую очередь нужно обратить внимание при инструктаже персонала:
- Запрещается передача логинов и паролей. В первую очередь, между коллегами. Т.е. когда условный Вася дал свои данные «погонять» условному Пете. Если Пете нужен куда-либо доступ – оформите его официально. Помните – за все действия под конкретным логином отвечает владелец логина.
- Предотвращайте утечки информации. Выгрузки баз, какие-то документы заказчика в электронном и/или бумажном виде. Такие утечки могут довести до уголовного преследования в том числе. Например, у заказчика сервер «тормозит», решили быстро базу скопировать, чтобы разобраться у себя «по-быстрому» с проблемой.
- Конфиденциальность данных – не разглашайте в общественных местах, соцсетях. Не теряйте документы. Не пересылайте их по незащищенным каналам связи (например, общедоступные мессенджеры, электронная почта).
- Вообще, ИБ внимательно следит за активностью в соцсетях – следите за этим постоянно, пожалуйста.
- Качество разработки, аккуратность поведения в постороннем контуре. Не допускайте несознательного (тем более – сознательного) вредительства. «Ой, я нечаянно удалил журнал регистрации 1С за год» или «Удалил, место чтоб почистить» и таких примеров сотни. Не надо самодеятельности. Если нужно что-то удалить – обращайтесь к представителю заказчика по установленным у него регламентам.
И обязательно (повторимся) проводите тренинги и «учебные тревоги» среди сотрудников. Без тренировки теоретическая информация и «страшилки» быстро выветриваются из голов.
В завершение статьи приведем пример такого тренинга из реальной жизни: «Учебная атака».
Протестировали одну проектную команду таким образом – им было разослано фальшивое письмо (содержание видно на картинке выше) с фишинговой ссылкой внутри. Типа ошиблись адресом a86;
Разослано было 275 таких писем.
С теми, кто ответил – дальше продолжалась живая коммуникация.
Открыло фишинговое сообщение 68 человек. Т.е. заинтересовались «ведомостью за январь».
Включилось в общение и в итоге перешло на страницу, похожую на их проектный портал, где нужно было указать свой логин и пароль «для авторизации» – 49 человек.
10 человек ввели логин и пароль...
И это в проекте, где присутствуют регулярные тренинги и инструктажи по информационной безопасности.
Если нет времени или квалификации проводить тренинги по ИБ самостоятельно – отправьте сотрудников на курсы. Есть платные, есть бесплатные. У нас неплохой уровень консалтинга по ИБ, например – обращайтесь, договоримся!
Поверьте, с каждым годом ситуация с ИБ будет становиться всё острее, а требования заказчиков – расти. И чем раньше вы начнете заниматься информационной безопасностью у себя и своих клиентов, тем лучше.
