Zip File, мамкины хаЦкеры. В прошлом видео мы с вами рассмотрели особенности информационной безопасности в финансовой сфере. Сегодня предлагаю поговорить о международных и отраслевых стандартах, наиболее часто встречающихся в ИБ. Вы узнаете кто разрабатывает стандарты, их типы, разделение по способу подтверждения, как применяются стандарты и какие из них активно используются в России. Так что, если вам интересна данная тема, устраивайтесь по удобней, наливайте чаёк-кофеёк и будем вместе погружаться в мир душноты и отечественного инфобеза. Погнали.

Любой стандарт – это, по сути, некий эталон с которым мы что-то сравниваем. В ГОСТе Р 1.12 2004 года дано официальное определение национальному стандарту. Запоминать его не нужно, просто знайте где можно его отыскать.

Сами стандарты применяются для повышения качества чего-либо и решения конкретных задач.  Например, они устанавливают требования к техническому уровню и качеству продукции, а также содействуют взаимопроникновению технологий в различных отраслях экономики.

По типу стандарты бывают международные (ISO, IEC), межгосударственные (ГОСТы), национальные, в том числе и идентичные мировым (это ГОСТ Р и ИСО/МЭК), отраслевые и стандарты организаций.

Стандарты ИБ

Теперь давайте разберёмся кто вообще пишет стандарты по ИБ и какие стандарты уже написаны. Одну из основополагающих серий стандартов ISO/IEC 27 серии разработала международная организация ISO.

Стандарты эти платные, во всяком случае для коммерческого использования. Ну а для учебно-ознакомительных целей, всегда можно воспользоваться сливами и качнуть их на форумах. Там все эти стандарты плюс-минус в актуальной редакции найти можно.

Следующая организация, которая пишет достаточно много стандартов – это NIST. Американский национальный институт стандартов, который пишет стандарты для всего на свете, в том числе и по части ИБ.

Речь идёт об SP. 800 серия. Они бесплатные. Там только одних нистов штук 200. На каждый чих. Безопасность вай фая – стандарт. Безопасность блютуза – стандарт. Безопасность какого-нибудь NFC – ещё один стандарт.

У нас в России они не обязательные и в целом не очень распространены, но в качестве базы знаний для решения определённых вопросов использовать можно. Я, например очень часто в эти стандарты подглядываю по долгу службы.

Что же касается обязательных стандартов, то у нас такие в основном разрабатывает ФСТЭК, под эгидой которого создан так называемый комитет по стандартизации «Защита информации» более известный как ТК 362.

В комитет входит более 100 различных организаций. Это и научно-исследовательские объединения и крупные коммерческие организации. Теоретически любая организация может вступить в комитет для участия в коллегиальной деятельности по написанию этих стандартов.

Коллегиально этим нужно заниматься для того, чтобы согласовать различные мнения и подходы. А иначе эти стандарты будут попросту игнорироваться на местах.

Аналогичный комитет есть и под патронажем ФСБ. Называется он ТК 26. Это технический комитет по стандартизации «Криптографическая защита информации». Там в основном занимаются вопросами криптографии.

Помимо этого, хотелось бы обратить ваше внимание на международные проект Common Criteria, в котором собраны общие критерии ИБ под кодовым названием ISO/IEC 15408.

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

После такой проверки объекту, например операционной системе, как правило, присваивается определённый уровень доверия, который является показателем для всего сообщества безопасников.

Банки, если мне не изменяет память, оцениваются по 4 уровню доверия. Причём опираются именно на данную международную практику, хоть по факту и в рамках аналогичного ГОСТа.

Ещё на большой земле существует такая организация, как CIS. Центр безопасности интернета. У данного центра на текущий момент всего 2 крутых наработки. Первая – это CIS Control.

Набор практик с конкретными рекомендациями по ИБ для малых контор. Там их в районе двадцатки этих советов. И CIS benchmarks, наборы инструкций с алгоритмами настройки функций безопасности от разработчиков.

На Винду, на Оракал, на Android, Apache, Кибернетес. Короче на всё-всё-всё вы сможете найти соответствующие настройки в этих бенчмарках. И самому в интернете искать не надо. Всё собрано в одном месте.

Для веб-разработчиков и любителей покодить для мобилок есть отдельный проект OWASP направленный на повышение безопасности именно в этой области. Проект активно развивается с 2001 года и имеет большое комьюнити по всему миру.

Кстати, о разработке. Если вам необходима надёжная база для практики, рекомендую обратить внимание на проверенный сервис SptintBox, о котором я уже неоднократно упоминал в своих роликах.

Отличие Спринтбокс от обычного хостинга в том, что тут ресурсы не распределяются между всеми аккаунтами на сервере. Каждому пользователю выделяется собственный набор вычислительных мощностей.

Благодаря этому, вы не будете зависеть от соседей по серверу и сможете делать со своими боксами, буквально, что захотите. Так что если намерены создать какой-то сложный проект для которого обычный хостинг никак не годится, боксы это хорошая альтернатива.

Помимо прочего на сервисе можно настроить резервное копирование и снапшоты, подключаться к серверам по SSH и FTP, добавить к ним дополнительное хранилище до 1 Тб.

Ну и само собой поиграться с настройками файрвола и подключить защиту от внешних DDoS-атак. Короче для сетевой практики это прямо мастхэв. Можно запросто деплоить ботов для Телеграма, ВК и Дискорда.

Накатывать готовые дистрибутивы или ставить свои собственные сборки ОСей. Можно поднять сервер Майнкрафт для игор с корешами. Принцип, как в Лего. Вы ограничены только умениями и рамками вашей фантазией.

Есть даже дистрибутивы с VPN, поднять которые не составит труда даже для тех, кто только начинает свой путь в IT.

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

Если вдруг тупанёте и не сможете разобраться, вам на помощь придёт техподдержка. Там ребята всегда на связи. И днём, и ночью. Кроме того, можно воспользоваться Базой знаний, в которой есть масса полезных статей.

В общем, если хотите изучать системы и сети не только в теории, а действительно погрузиться в эту историю с головой – велком. Ссылка на KVM VDS от SprintBox будет в описании.

Там же будет мой фирменный промокод, по которому ещё и 50% кешбек получите. Короче переходите скорее и регайтесь. Не пожалеете. Сам пользуюсь уже несколько лет и доволен как слон.

Ещё одна организация, связанная со стандартами – это PCI SSC. Совет по стандартам безопасности в области платёжных карт и систем. VISA, MasterCard, American Express, Discover, все эти истории используют стандарт PCI DSS Payment Card.

Фишка стандарта заключается в том, что в Америке до сих пор распространён вид мошенничества с магнитной полосой на картах. Да-да, это у нас в загнивающей России мы все карты с чипами выпускаем, а там…ну вы поняли.

Короче по PCI DSS точка, которая принимает карточные данные не должна хранить её данные. Т.е. если вы расплатились где-нибудь на заправке, хитрый владелец не сможет слить ваши данные на магнитку и наклеить на свежий пластик.

Ладно. То дела пендосские. Давайте вернёмся в прогрессивную Россиянию. У нас тут помимо ФСБ и ФСТЭКа свой нос в стандарты ИБ любит совать центробанк.

Так, данный регулятор является автором серии СТО БР ИББС, а также положений, содержащих различные требования в плане ИБ для кредитных и некредитных финансовых организаций.

Часто используемые стандарты

В общем и целом, стандарты делятся на обязательные и необязательные. И те и другие могут быть подтверждаемыми или не подтверждаемыми формальным процессом.

К примеру, PCI DSS это обязательный стандарт. И тот кто его применяет должен проходить раз в год специализированный аудит на соответственные. По итогу аудита получать соответствующий подтверждающий документ, подписывать и отправлять в совет PCI SSC.

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

Затем понять, какие внешние стандарты для неё будут обязательны к применению. Далее определить иные требования партнёров или головной организации в случае с филиалом.

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

Семейство стандартов ISO 27XXX

ISO 27000 это семейство стандартов, которые посвящены выстраиванию процессов управления ИБ. Ключевая идея заключается в систематичном подходе к анализу рисков.

Идея эта не новая. В ISO есть стандарт по управлению непрерывностью бизнеса и звучит он плюс-минус аналогичным образом. Если ты хочешь построить грамотный бизнес, то построй систему управления непрерывностью бизнеса, а остальное по ходу дела приложится.

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

Стандарт ISO 27000 является провопреемником стандарта BS 7799. В 2006 появилась его обновлённая локализованная версия, которую, по существу, довели до ума только лет 10 назад.

Правда локализовывать официально не стали. Нет, в сети можно найти переведённую версию, но это паль. Вообще глобально в IT все документы, программы, код, всё написано на английском. Так что учите. Это мастхэв.

Стандарт, в частности 27001 можно применять, как неформально, это когда вы открываете его, читаете, мысленно соглашаетесь с тем, что там так красиво написано и начинаете применять эти рекомендации на своём предприятии.

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

После того, как вы эту систему реализовали, определили роли, написали регламенты, заставили всех сотрудников их выполнять, вы проводите аудит на основании которого вам выдают сертификат соответствия СУИБ.

Такой документ, как минимум, повышает ценность вашей организации. А как максимум, делает её более привлекательной для внешних партнёров. Само семейство ISO 27000 насчитывает более 40 различных стандартов.

Базовыми среди них являются 27000, 27001 и 27002. Остальные же являются вспомогательными стандартами по различным аспектам информационной безопасности, которые можно учесть, но большинство серьёзных компаний всё таки эти допники либо переделывают, либо вообще игнорируют.

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

Если упростить всё до бытовых примеров и рассмотреть ситуацию, когда кошка запрыгивает на стол и задевает вазу, то тут ваза является активом представляющим ценность, действия кошки – это угроза, но сама кошка при этом угрозой являться не может.

Риски оцениваются исходя из возраста кошки, состояния её здоровья и склонности к подобным поступкам. Хрупкая ваза – это явная уязвимость. Ну а прыжок это уже конечно атака.

При этом вся эта ситуация в целом – риск. Такая вот нехитрая цепочка, друзья мои. При этом для того, чтобы избежать в будущем таких рисков можно сделать ножки стола значительно выше и тогда котэ не сможет допрыгнуть.

Либо можно убрать кошки из комнаты и не пускать. В конце концов можно переставить вазу и не оставить на поверхности стола хрупких предметов. Короче вариантов достаточно, надо лишь врубить фантазию в режим ON.

Ну а теперь давайте перейдём от бытовых примеров к айтишым. Так на слайде рассмотрен пример угрозы получения доступа к корпоративным ресурсам через Wi-Fi сеть. Рассмотрите его самостоятельно в качестве практики.

А мы пока более подробно пробежимся по официальным определениям из ISOшки. Угроза — это прежде всего возможная причина нежелательного инцидента, который может нанести ущерб вашей организации.

Угроза никак не зависит от чьей-то оценки. Она в принципе не может быть объективно оценена. Возможна лишь субъективная оценка вероятности реализации.

У ФСТЭКа, к слову, есть целый отдельный “Каталогах угроз”, называемый без лишней скромности банком данных угроз ФСТЭК. Если не забуду, продублирую вам ссылку на него в описании к ролику. Ну а если забуду, то гугл в помощь.

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

Уязвимость может быть выражена в виде:

● ошибки в коде;

● настройке;

● отсутствии обновлений;

● ошибки архитектуры;

● неправильно выданных прав;

● и даже в форме человеческого косяка (например, пользователем установлен слабый пароль).

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

Наиболее простое и понятное говорит, что риск – это влияние неопределённости на цель. Т.е. у нас есть цель и всё что может на неё как-либо повлиять – это риск. Причём риск в данном случае не обязательно негативный. В покере ведь рискуют для того, чтобы выиграть.

У нас безопасники очень часто термин риск подменяется термином “актуальная угроза”. Это когда актуальной считается угроза, которая может быть реализована в ИСПДн и представляет опасность для персональных данных.

Но благо тут вас в творчестве никто не ограничивает. “Правильной” и “лучшей” методологии просто не существует. Поэтому каждый специалист по ИБ волен выбрать любую методологию оценки рисков, которая больше подойдет ему и его организации.

Основной смысл анализа рисков заключается в том, чтобы не потратить на защиту больше, чем мы можем потерять в случае реализации угрозы. Допустим у вас есть машина стоимостью 1 миллион. Какой-нибудь солярис подержанный.

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

Оценка рисков может быть количественной и качественной. Количественную очень любят руководители, т.к. её удобно померять и что называется взвесить в граммах.

Ну а качественная в разы демократичней и проще. Её, как правило, любят гуманитарии. Но повторюсь, единой «правильной» и «лучшей» методологии не существует.

Главное, чтобы перед началом работ по оценке рисков методика была согласована всеми заинтересованными сторонами. Т.е. чтобы и бизнес был согласен с таким подходом и ИБшник мог в его рамках исполнять свои прямые обязанности.

Вообще согласно модели Дёминга любой процесс, в том числе оценку рисков, можно улучшить в 4 этапа. Просто составь план, сделай, проверь, и, если что-то сделалось не так – исправь.

Потом снова запланируй, снова сделай, проверь и снова исправь. Таким образом любой процесс можно совершенствовать до бесконечности. Это очень эффективный подход практически к любой ситуации.

Не зря эта модель PDCA (ПиДиСей) легла в основу стандарта ISO 27001. Там все блоки по логике как раз разбиты на разделы согласно упомянутой модели Дёминга.

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

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

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

Окей, друзья. Я, как всегда, под конец выпуска начинаю нести ахинею и дабы не форсировать мой мозговой высер, давайте подведём итоги нашего сегодняшнего урока.

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

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

Ну а к данной ветке развития вы всё равно рано или поздно придёте. Либо кали линукс в какой-то момент заипёт, либо просто захотите нормально озолотиться и поменять кредитный солярис на бентли.

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

Не забываем делать домашку. Я её уже выложил на сайте и очень жду что вы пришлёте правильные ответы. Ссылка, как водится, будет в описании под видосом.

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