Cloud Security. Cloud Security Alliance (CSA) Guidance. Part 1. || Безопасность Облаков. Лучшие практики. Фреймворк от Cloud Security Alliance (CSA). Часть 1.

In Russia when we are talking about "Information security" it's often the case to discuss law, regulations, perimeter defending (or it no longer exists again), security products, SOC and even Security as a Service. We don't talk much about such an important area as the Cloud Security, and it is not a regular part of our industry events. However, cloud technologies are confidently moving around the world and I'm convinced that in the near future they'll break the ice in Russia. Just look at .gov services (e.g. we can order a new passport directly from our mobile phone), smart cities, industrial IoT, whatever. Thus clouds will come inevitably. There will be clear future, our controllers will issue regulatory requirements. By the way, without ones it is difficult to force organizations to consider about cloud security, isn't it? No matter what country you're from, it may be usefull to talk about the "golden" standard in cloud security from Cloud Security Alliance - "Security Guidance for Critical Areas of Focus in Cloud Computing" and the CCM - "Cloud Controls Matrix" (a cybersecurity control framework, composed of 133 control objectives that are structured in 16 domains covering all key aspects of the cloud technology). Let's do it with a short review, starting with the Part 1 in this post. 

Introduction

Document CSA Security Guidance for Critical Areas of Focus in Cloud Computing has been developing from 2009 and now the current version is 4.0 (2017), it can be downloaded from official web resource after the registratioin. First of all, document is good because it is by-design based on cloud-native concept and models. It's necessary to clearly understand all key features of the cloud technology and difference from classic IT acrchitecture, otherwise you won't get all tremendous benefts in agility, resiliency, and economy. The Guidance is structured by 14 domains: 

The domains are divided into two broad categories: governance and operations. The governance domains are broad and address strategic and policy issues within a cloud computing environment, while the operational domains focus on more tactical security concerns and implementation within the architecture. I'd like to highlight, that a detailed description about particular security tasks is provided in each domain. It's important and usefull to show how cloud security model can be distinguished from classic on-prem one.

Domain 1. Cloud Computing Concepts and Architectures.

Let's get started with basic concepts. CSA has created the document in accordance with best well-known practices and guidances in the field of cloud computing. I'd like to notice NIST SP 800-145 “Definition of Cloud Computing” and ISO 17789 “Information technology — Cloud computing — Reference architecture”. As for me, the best definition of the main term is contained in the second one: "Cloud computing" -  paradigm for enabling network access to a scalable  nd elastic pool of shareable physical or virtual resources with self-service provisioning and administration on-demand. Two key The key techniques to create a cloud are abstraction and orchestration. We abstract the resources from the underlying physical infrastructure to create our pools, and use orchestration (and automation) to coordinate carving out and delivering a set of resources from the pools to the consumers. As you will see, these two techniques create all the essential characteristics we use to define something as a "cloud". In other words, multitenancy is a native property of cloud technologies. Diving deeper, all cloud services can be defined through 5 essentials characteristics, 3 cloud service models, and 4 cloud deployment models.

Essentials characteristics:

1. Broad network access - means that all resources are available over a network, without any need for direct physical access; the network is not necessarily part of the service
2. Rapid elasticity - allows consumers to expand or contract the resources they use from the pool (provisioning and deprovisioning), often completely automatically. This allows them to more closely match resource consumption with demand (for example, adding virtual servers as demand increases, then shutting them down when demand drops)
3. Measured service - meters what is provided, to ensure that consumers only use what they are allotted, and, if necessary, to charge them for it. This is where the term utility computing comes from, since computing resources can now be consumed like water and electricity, with the client only paying for what they use
4. On-demand self-service - means that consumers provision the resources from the pool by themselves, without having to talk to a human administrator
5. Resource pooling - means that the provider abstracts resources and collects them into a pool, portions of which can be allocated to different consumers (typically based on policies)

Service models:

1. SaaS - Software as a Service – is a full application that’s managed and hosted by the provider, consumers access it with a web browser, mobile app, or a lightweight client app
2. PaaS – Platform as a Service – abstracts and provides development or application platforms, such as databases, application platforms (e.g. a place to run Python, PHP, or other code), file storage and collaboration, or even proprietary application processing (such as machine learning, big data processing, or direct Application Programming Interfaces (API) access to features of a full SaaS application)
   
   
   
3. IaaS – Infrastructure as a Service – offers access to a resource pool of fundamental computing infrastructure, such as compute, network, or storage
   

Deployment Models:

1. Public cloud –  the cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services
2. Private cloud - the cloud infrastructure is operated solely for a single organization, it may be managed by the organization or by a third party and may be located on-premises or offpremises
3. Community cloud – the cloud infrastructure is shared by several organizations and supports a specifc community that has shared concerns (e.g. mission, security requirements, policy, or compliance considerations), it may be managed by the organizations or by a third party and may be located on-premises or off-premises
4. Hybrid cloud – the cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds)
   
   
   

As a result, cloud service models can be represented in the following diagram: 

Finally, it's important to mention about logical layers model based on functionality. This is useful to illustrate the differences between the different computing models themselves. From bottom-to-top they can be divided into

4 logical levels:

1. Infrastructure – the core components of a computing system: compute, network, and storage. The foundation that everything else is built on. The moving parts.
2. Metastructure – the protocols and mechanisms that provide the interface between the infrastructure layer and the other layers. The glue that ties the technologies and enables management and confguration
3. Applistructure – the applications deployed in the cloud and the underlying application services used to build them. For example, Platform as a Service features like message queues, artifcial intelligence analysis, or notifcation services.
4. Infostructure – the data and information. Content in a database, fle storage, etc.

The key difference between cloud and traditional computing is the metastructure. Cloud metastructure includes the management plane components, which are network-enabled and remotely accessible. Another key difference is that, in cloud, you tend to double up on each layer. Infrastructure, for example, includes both the infrastructure used to create the cloud as well as the virtual infrastructure used and managed by the cloud user.  Now it's time to move closer to the security.

Cloud Security Scope and Models

In each specific cloud service model, it is logical to divide the areas of responsibility for security between the provider and the client.

1. SaaS – the cloud provider is responsible for nearly all security, since the cloud user can only access and manage their use of the application, and can’t alter how the application works. For example, a SaaS provider is responsible for perimeter security, logging/monitoring/auditing, and application security, while the consumer may only be able to manage authorization and entitlements.
2. PaaS – the cloud provider is responsible for the security of the platform, while the consumer is responsible for everything they implement on the platform, including how they confgure any offered security features. The responsibilities are thus more evenly split. For example, when using a Database as a Service, the provider manages fundamental security, patching, and core confguration, while the cloud user is responsible for everything else, including which security features of the database to use, managing accounts, or even authentication methods.
3. IaaS –  just like PaaS, the provider is responsible for foundational security, while the cloud user is responsible for everything they build on the infrastructure. Unlike PaaS, this places far more responsibility on the client. For example, the IaaS provider will likely monitor their perimeter for attacks, but the consumer is fully responsible for how they defne and implement their virtual network security, based on the tools available on the service.

Obviously, in each certain project the provider and the client have to negotiate about areas of responsibility. It’s less important if any particular cloud provider offers a specifc security control, as long as you know precisely what they do offer and how it works. You can fll the gaps with your own controls, or choose a different provider if you can’t close the controls gap. Your ability to do this is very high for IaaS, and less so for SaaS. This is the essence of the security relationship between a cloud provider and consumer. What does the provider do? What does the consumer need to do? Does the cloud provider enable the consumer to do what they need to? What is guaranteed in the contract and service level agreements, and what is implied by the documentation and specifcs of the technology? The Cloud Security Alliance (CSA) provides two tools to help meet these requirements:

1. The Consensus Assessments Initiative Questionnaire (CAIQ) - a standard template for cloud providers to document their security and compliance controls.
2. The Cloud Controls Matrix (CCM) - which lists cloud security controls and maps them to
   multiple security and compliance standards. The CCM can also be used to document security
   responsibilities. This tool will be reviewed in next parts.

Cloud security models are tools to help guide security decisions. The term “model” can be used a

little nebulously, so for our purposes we break out the following 

model types:

1. Conceptual models or frameworks – include visualizations and descriptions used to explain cloud security concepts and principles, such as the CSA logical model in this document.
2. Controls models or frameworks – categorize and detail specifc cloud security controls or categories of controls, such as the CSA CCM.
3. Reference architectures – are templates for implementing cloud security, typically generalized (e.g. an IaaS security reference architecture). They can be very abstract, bordering on conceptual, or quite detailed, down to specifc controls and functions.
4. Design patterns – are reusable solutions to particular problems. In security, an example is IaaS log management. As with reference architectures, they can be more or less abstract or specifc, even down to common implementation patterns on particular cloud platforms.

Oviously, architecture solutions and certain security measures strongly depend on specific provider, using techlogies and basic requirements. However, any organization can follow regular steps to achieve results, there is a relatively straightforward, high-level 

process for managing cloud security:

1. Identify necessary security and compliance requirements, and any existing controls 
   
2. Select your cloud provider, service, and deployment models
3. Define the architecture
4. Assess the security controls
5. Identify control gaps
6. Design and implement controls to fill the gaps
7. Manage changes – this is an absolutely necessary step, because security is not a project, but a continuous process, so you need to review your model and controls

In summary, when we are about to start cloud security project, it will be useful to emphazise common but 

important recommendations:

1. Really clearly understand the differences between cloud computing and traditional infrastructure or virtualization, and how abstraction and automation impact security
2. Use existing best practices, models and tools, such as NIST model for cloud computing and the CSA reference architecture
3. Use tools such as the CSA Consensus Assessments Initiative Questionnaire (CAIQ) to evaluate and compare cloud providers
4. Ensure, that cloud provider clearly document its security controls and features and publish them using tools like the CSA CAIQ
5. Use tools like the CSA Cloud Controls Matrix to assess and document cloud project security and compliance requirements and controls, as well as who is responsible for each
6. Use a cloud security process model to select providers, design architectures, identify control gaps, and implement security and compliance controls

In the introductory Domain 1 CSA authors describe the fundamentals. They help us answer two main questions that should be in our mind before launching a cloud (of course with security) project:

1. What's it all about?
2. What should we start with?  

The following 13 Domains are more specific and directly focus on strategic and tactical cloud security implementations.

To be contunued. Stay tuned.

Stay on the light side. R.Z.

Когда мы поднимаем тему «Информационной безопасности» в России обычно обсуждаются законы, регуляторы, периметр и в очередной раз его отсутствие, средства защиты информации, даже, прости господи, SOC и аутсорсинг ИБ. Про безопасность облачной инфраструктуры у нас говорить особо не принято, и эта тема обычно не в топе отраслевых мероприятий. Я верю, что этот тренд сломается в обозримом будущем. Посмотрите хотя бы на то, что представляют из себя современные «Госуслуги», куда развиваются «Безопасные города», «Умные производства» и т.п. И вот тогда заживем: нашим регуляторам некуда будет деваться, придется писать требования и рекомендации для облаков, ведь без них у нас дела идут туго, «поднадзорные» бездельничают. Откуда брать идеи? Поскольку в Рунете я не смог найти обзорного описания нижеуказанных документов, в сегодняшней заметке поговорим о «золотом» стандарте в этой области - документе от Cloud Security Alliance (Международное объединение по безопасности облаков) – «Security Guidance for Critical Areas of Focus in Cloud Computing» и немного о CCM - Cloud Controls Matrix (набор конкретных мер по безопасности облаков).

Введение

Документ CSA Security Guidance for Critical Areas of Focus in Cloud Computing разрабатывается с 2009 года, текущая актуальная редакция v.4.0 от 2017 года (загрузка доступна на официальном сайте после короткой процедуры регистрации). Хорош он, прежде всего, тем, что сразу отталкивается от cloud-native моделей и в первых разделах предупреждает о том, что «нельзя так просто взять и перенести классические приложения в облако», в этом нет смысла, т.к. нивелируются преимущества облаков. Документ структурирован по 14 доменам:

1. Архитектура и концепции облачных вычислений
2. Управление рисками
3. Юридические вопросы, сервисные договоры, доступы третьих лиц
4. Соответствие требованиям и аудиты
5. Управление информацией (данными) и доступом
6. Менеджмент структуры управления и планирование восстановления в облаке
7. Безопасность облачной инфраструктуры
8. Безопасность виртуализации и контейнеризации
9. Реагирование на инциденты
10. Безопасность приложений
11. Защита данных и шифрование
12. Управление правами и доступом
13. Безопасность как сервис
14. Сопутствующие облакам технологии

Домены 1-5 образуют группу управленческих мер (Governance), которые покрывают широкий спектр стратегических (и даже политических) вопросов, связанных с облаками, позволяют выработать верхнеуровневые концепции. Домены 6-14 отвечают за операционную безопасность (Operations), то есть направлены на решение тактических и технических задач, описывают конкретные защитные механизмы в облачной инфраструктуре.Важно, что в каждом домене описывается, в том числе, как и почему рассматриваемая задача безопасности для облака отличается от задачи для классической корпоративной (on-prem) архитектуры. 

Домен 1. Архитектура и концепции облачных вычислений (Cloud Computing Concepts and Architectures).

Начнем с базовых понятий и архитектур облаков. CSA разрабатывал документ с учетом лучших общепризнанных практик по облакам, синхронизирован с соответствующими понятиями и определениями. Основными являются NIST SP800-145 “Definition of Cloud Computing” («Облачные вычисления») и ISO 17789 “Information technology — Cloud computing — Reference architecture” («Информационные технологии. Облачные вычисления. Эталонная архитектура»). Лично мне нравится определение основного термина из второго, оно более лаконичное: «Облачные вычисления» (“Cloud computing”) – это концепция осуществления удаленного доступа к масштабируемой и гибкой инфраструктуре, состоящей из разделяемых физических или виртуальных ресурсов, с возможностью самостоятельного управления ими пользователем облака (клиентом). Двумя ключевыми параметрами, определяющими облако, являются абстракция и оркестрация. Мы абстрагируемся от конкретных физических ресурсов для создания «облачного пула ресурсов» и используем автоматизированную оркестрацию для координации, выделения и доставки ресурсов из этого пула пользователям (облачным клиентам). Второе как раз и отличает облака и традиционную виртуализацию, ведь облака – многопользовательские (multi-tenant) по определению, где каждый пул ресурсов разграничен друг от друга. Погружаясь глубже, NIST определяет облака через 5 основных характеристик, 3 сервисные модели и 4 модели развертывания. 

Основные характеристики (essentials characteristics):

1. Доступ отовсюду (Broad network access) – клиент облачного провайдера имеет доступ к своему пулу отовсюду (где есть интернет), без необходимости каким-либо образом организовывать специальный канал до облака
2. Быстрое масштабирование (Rapid elasticity) – позволяет клиентам увеличивать или уменьшать потребляемые облачные ресурсы самостоятельно и желательно полностью автоматически (в пределах условий использования и контракта) в зависимости от реальной потребности
3. Измеримое потребление (Measured service) – означает обязанность облачного провайдера измерять (биллинговать) потребляемые клиентом сервисы и начислять соответствующую плату за их использование (подобно воде и электричеству в квартирах)
4. Самостоятельное управление своим пулом (On-demand self-service) – клиенты провайдера не привлекают администраторов, а сами управляют своими ресурсами
5. Создание пула ресурсов (Resource pooling) – облачный провайдер создает пулы ресурсов, которые выделяет своим клиентам

Сервисные модели (service models):

1. Софт как сервис (SaaS - Software as a Service) – предоставление доступа к конкретному приложению (по web, через мобильное приложение или иным удаленным способом)
2. Платформа как сервис (PaaS – Platform as a Service) – предоставление абстрактной платформы (базы данных, интерпретатора какого-либо языка и т.п.), файлового хранилища или интерфейса (например, API) к технологии (машинное обучение, работа с большими данными)
   
   
   
3. Инфраструктура как сервис (IaaS – Infrastructure as a Service) – предоставление доступа к базовым элементам инфраструктуры: компьютер, сеть или хранилище
   

Модели развертывания (Deployment Models):

1. Публичное облако (Public cloud) – инфраструктура предоставляется облачным провайдером широкому кругу клиентов (не только лишь в рамках одной организации)
2. Частное облако (Private cloud) - инфраструктура предоставляется в рамках одной организации (или группы компаний), при этом облако может управляться (располагаться) как самой организацией, так и аутсорсинговым провайдером (но только в интересах этой организации)
3. Облако сообщества (Community cloud) – инфраструктура предоставляется нескольким организациям в рамках созданного ими объединения на основании общих интересов (одна миссия, задача, требования или политики безопасности и т.п.), при этом облако может управляться (располагаться) как одной из таких организаций, так и аутсорсинговым провайдером (но только в интересах этих организаций)
4. Гибридное облако (Hybrid cloud) – облачная инфраструктура построена исходя из комбинации моделей (1-3), но объединена общим технологическим подходом. Гибридным облаком также часто называют необлачный ЦОД, подключенный к облачному провайдеру.
   
   
   

Таким образом, обобщая, архитектурно модели предоставления сервисов можно представить следующим образом: 

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

Выделяют 4 логических уровня от нижнего – к верхнему:

1. Инфраструктура (Infrastructure) – компьютеры, сети, хранилища, т.е. фундамент всех остальных логических уровней
2. Метаструктура (Metastructure) – протоколы и механизмы, обеспечивающие интерфейс обмена данными между уровнем инфраструктуры и остальными уровнями (связка базовых технологий и способов управления)
3. Апплиструктура (Applistructure) – приложения и сервисы, развернутые в облаке для работы пользователей (например, к ним относятся PaaS инструменты, такие как ML/AI-анализ, службы уведомлений, сервис очереди сообщений)
4. Инфоструктура (Infostructure) – информация и данные (в базах данных, хранилищах и т.п.)

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

Границы ответственности и модели безопасности.

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

 

1. SaaS – на провайдере лежит максимум ответственности за безопасность, поскольку при такой модели он предоставляет клиенту софт и тот должен заботится, пожалуй, только о ролях и доступе, тогда как защиту периметра, логирование, аудит, защиту приложения обеспечивает провайдер
2. PaaS – провайдер отвечает за безопасность платформы (например, патчинг БД, безопасность самого сервера БД), а клиент – за все остальное, включая пользователей (в т.ч. администраторов), схемы управления доступом и безопасности
3. IaaS – клиент полностью отвечает за безопасность выделенной ему виртуальной инфраструктуры, провайдер защищает только периметр и средства построения этой инфраструктуры

Конечно, в каждом конкретном проекты провайдер и клиент должны договариваться о том, как именно будут разграничены зоны ответственности. При этом выбор защитных мер сильно зависит от возможностей самого облака. Многие провайдеры предоставляют максимально полный набор защитных сервисов для своих клиентов по тем же самым трем моделям на выбор. Однако, никто не запрещает клиенту внедрять свои собственные решения. CSA предоставляет 2 удобных инструмента, которые помогут провайдеру и клиенту документировать разделение зон ответственности и выбрать необходимый набор мер безопасности. Первый – Чек-лист с вопросами для оценки соответствия и документирования (Consensus Assessments Initiative Questionnaire (CAIQ)). Второй – Матрица мер безопасности для облаков (Cloud Controls Matrix (CCM)), о ней мы еще поговорим отдельно.

Чтобы построить комплексную безопасность облаков, очевидно, необходим некий инструментарий (framework): стандарты, инструкции, руководства, примеры, иными словами, модель безопасности. Говоря о моделях безопасности и способах их построения, необходимо различать следующие

уровни абстракции:

1. Концептуальная модель (Conceptual models or frameworks) – нужна, чтобы принять базовые архитектурные принципы безопасности (например, утвердить, что мы отталкиваемся от модели 4-х логических уровней, которые описывали чуть выше)
2. Модель мер безопасности (Controls models or frameworks) – категорирует и детализирует конкретные применяемые меры безопасности (организационные и технические), если необходимо – в соответствии со стандартами или нормативными требованиями
3. Эталонная архитектура (Reference architectures) – шаблоны (и примеры) построения архитектуры безопасности для конкретной сервисной модели (SaaS, PaaS и IaaS), могут описываться конкретные решения или классы средств защиты
4. Шаблоны проектирования защитных мер (Design patterns) – описывают реализацию конкретной технологии, направленной на решение какой-либо задачи безопасности (например, лог-менеджмент, защита приложения и т.п.), могут описываться конкретные решения или классы средств защиты

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

процессы безопасности:

1. Определение требований (Identify requirements) – определение и утверждение необходимых верхнеуровневых требований по безопасности, в том числе исходя из специфики нормативного регулирования, каких-либо внутренних документов и собственного опыта (видения)
2. Выбор провайдера и моделей (Select Provider, Service, and Deployment Models) – важно не просто выбрать лучшего провайдера на рынке, но и сразу учитывать потребности в конкретных сервисных услугах и моделях развертывания
3. Определить архитектуру (Define the architecture)
4. Оценить существующие меры безопасности (Assess the security controls)
5. Выявить недостающие меры безопасности (Identify control gaps)
6. Спроектировать и внедрить недостающие меры безопасности (Design and implement controls)
7. Управлять изменениями (Manage changes) – безопасность – это, несомненно, не проект, а процесс, поэтому необходимо периодически оценивать изменившуюся обстановку и пересматривать модель и меры безопасности

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

полезных и важных рекомендаций:

1. Важно действительно понять разницу между традиционной инфраструктурой, классической виртуализацией и облачной парадигмой, а также как на безопасность влияют абстракция и оркестрация
2. Используйте уже существующие подходы, модели и лучшие практики построения облачной инфраструктуры и обеспечения безопасности (NIST, CSA)
3. Используйте CSA CCIQ и CCM для формализации отношений с провайдером
4. Облачный провайдер обязан предоставить полную информацию обо всех принимаемых мерах безопасности, в идеале, если клиенту предоставляется выбор из них
5. Нужно разграничить зоны ответственности (можно использовать CCM) между провайдером и клиентом, с учетом требований и нормативных особенностей в разрезе каждой меры безопасности
6. Двигайтесь по описанной выше пошаговой последовательности при построении системы безопасности (выбирайте провайдера, определяйте архитектуру, стройте модели и т.д.)

В вводном Домене 1 описаны базовые вещи, позволяющие ответить на 2 главных вопроса при выборе любой новой для себя технологии. Первый – «что это такое?». Второй –«с чего начать?». Следующие 13 Доменов уже более конкретные и посвящены непосредственно вопросам построения облачной безопасности.

Продолжение следует, не переключайтесь.

Оставайтесь на светлой стороне. R.Z.

Свежий Gartner Hype Cycle и информационная безопасность

Неделю назад уважаемое агентство Gartner опубликовало свежий обзор «The Gartner Hype Cycle for Emerging Technologies 2020». Исследование касается новых технологий (ИТ и не только) в общем, и в сети уже появилось немалое количество переводов на русский. В заметке я хочу поделиться своими мыслями, как публикация касается темы нашей с вами информационной безопасности. Ожидаемо, темы удаленки и COVID-19 нашли свое отражение в прогнозах аналитиков, но не ими едиными. Обо всем – по порядку.

Напомню, что Garter примерно раз в год выпускает свое видение по поводу актуальности, перспективности и продуктивности применения так называемых «прорывных технологий» в виде графика, который называется «Hype Cycle». Они разложены по 5-ти стадиям «хайпа о них» (триггер инновации, пик завышенных ожиданий, разрушение иллюзий, область просветления, плато продуктивности) и степени ожидания от них, а также времени прихода в нашу жизнь.

Собственно, сам Hype Cycle 2020 выглядит следующим образом:

Прямо из картинки можно сделать несколько занятных выводов.

Во-первых, развитие менее чем в 2-х годичной перспективе «Паспорта здоровья» и «Технологий социального дистанцирования». И это уже происходит, подтвердить, что вы «не заразный» с помощью приложений можно уже в Китае, Индии, Австралии, ОАЭ. А по поводу дистанции - буквально сегодня в FB видел рекламу сервиса по поиску коворкингов с соблюдением «режима»:

В эту же группу трендов можно отнести развитие в перспективе 2-5 лет BYOI («Принеси свою собственную идентичность»), а в 5-10 лет - «Подтвержденное происхождение», «Дифференциальная приватность» и «Цифровые двойники». Вызовы в контексте кибербезопасности здесь очевидны и аналогичны таковым в отношении цифровых паспортов, биометрии и т.п. Это – разного рода дипфейки, взломы, шантаж, мошенничество. Далеко не всегда текущие средства защиты способны противостоять такого рода угрозам, ждем появления новых (вроде «Подтверждение происхождения» и других). Кроме того, достаточно одного-двух «темных» случаев, чтобы отбросить степень доверия к технологии далеко назад, особенно, когда речь идет о здоровье или ограничении свобод. Поэтому, как мне кажется, разрушение иллюзий мы здесь еще увидим. Живя в мире постоянных утечек и фейков, уже трудно доверять кому-либо в принципе – тут я соглашусь с Gartner. Поэтому каждый будет стараться составить свой собственный «рейтинг доверия» (при этом, доверяя не источнику, а алгоритму), используя при этом базы с механизмами «избирательной приватности».

Во-вторых, не отпускает тема искусственного интеллекта и всего, что с ней связано. В 2-5 лет уложатся «Генеративный, состязательный и композитный ИИ», а в 5-10 лет - «Дизайн с помощью ИИ», «Двустороннее взаимодействие машина-человек», «Адаптивное машинное обучение», «Ответственный ИИ», «Дополненная ИИ разработка», «Объяснимый ИИ». Общий посыл – все больше разнообразных операций мы сможет доверить не просто роботам, а именно ИИ, который способен изменяться, подстраиваться, состязаться друг с другом в выборе лучшего варианта, словом, по-настоящему думать и принимать решения. Про Скайнет я рассуждать не буду, а вот более реалистичные примеры из сферы ИБ вполне имеют право на жизнь. Это было бы очень круто, если бы ИИ в условном SOC вылавливал реальную атаку, отбрасывая все false, а потом принимал решение об оптимальном сценарии реагирования, при этом на каждом шаге возможны новые внешние вводные + обучение на собственных же действиях. При этом закреплена его четкая ответственность, в идеале - с применением мер наказания. А иначе как направить энергию только в мирное русло, и не подсадить его на написание создание фейковых личностей, фейковых новостей и т.п. Кстати, по поводу последнего, совсем недавно выяснилось, что блог, который вел исключительно ИИ, стал самым популярным на ресурсе “Hacker news” среди обычных читателей.

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

В-третьих, наконец, массовая удаленка еще больше подхлестнула к быстрому внедрению корпоративной мобильности и связанной с ней автоматизации или, если хотите, коммодизации безопасности. В разрезе 2-5 лет ожидаем развитие «Встроенного ИИ», «Дешевых вычислений на конечных точках», а 5-10 лет - «Фабрик данных», «Частного 5G», SASE («Безопасный доступ как сервис»). Как мне кажется, движение в эту сторону и так активно идет, а новые технологии – это, скорее, просто упрощение и модернизация подходов Нулевое доверие («Zero trust», Безопасность как сервис, BYOD наивысшего уровня зрелости, Повсеместная контейнеризация и т.п. Периметра и так уже давно нет, видимо, скоро его не станет «совсем-совсем».

 

Выводы

Некоторые выводы Gartner я умышленно обошел стороной, поскольку они представляются делами уж совсем далекого будущего, либо лично мне менее интересными. Если сравнивать с предыдущими прогнозами Gartner, данный мне показался излишне однонаправленным и даже более осторожным. В остальном – обращаем внимание на то, что практическая безопасность (разве есть уже средства защиты от угроз новым технологиям? А ведь они уже среди нас!), увы, отстает от ИТ-трендов в целом, а злоумышленники, напротив, уже сегодня «вооружаются» самыми современными технологиями. Однако, принцип «когда петух клюнет» все же трансформируется в принцип «security by design», поэтому при сколь-нибудь широком распространении той или иной инновации, привлечение экспертизы ИБ неизбежно. Иначе – потребители самой технологии стремительно сокращаются. Мир слишком быстро меняется, и доверие – стало ключевой разменной монетой. А его, как известно, трудно заработать, но просто потерять.

Оставайтесь на светлой стороне.

Как новый ГОСТ по ГосСОПКА поможет выстроить процессы

В рамках руководства деятельностью технического комитета по стандартизации ТК362 («Защита информации») ФСТЭК любезно выложила проект нового ГОСТ «Защита информации. обнаружение, предупреждение и ликвидация последствий компьютерных атак и реагирование на компьютерные инциденты. Термины и определения». В этой заметке все пересказывать не буду, хочу подсветить то, что показалось мне интересным. А это, ни много ни мало, попытка описания структуры «типового SOC» и «каталога СЗИ».

Формально цели разработки документа декларируются, как «нац. и вообще безопасности». Но суть – в попытке создания единого понятийного аппарата, причем амбициозно согласованного с остальной массой документов. Творческий подход заметен сразу, например, есть следующие «адаптированные» врезки, передающие может не каждую букву (в отличие от официальных НПА), но кратко суть.

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

А вот - та самая обещанная структура SOC.

«Почему он ее так назвал?» - спросите вы, «ведь здесь речь только о ЦЕНТРЕ ГОССОПКА, а не о субъектах». Справедливо, однако, в практике встречаешь кучу разных толкований и есть случае применения к себе субъектами КИИ «требований к средствам ГосСОПКА». А у нас, как известно, если четкой нормативки нет, то нужно попытаться использовать хоть какую-то. Вспомните хотя бы широкое применение и адаптирование «Методики моделирования нарушителя ФСБ…» от 2008 года не только в ИСПДн и не только по отношению к СКЗИ. Итак, запасаемся попкорном и наблюдаем, как центры ГосСОПКА (а мб и субъекты КИИ) будут отстаивать свою возможную точку зрения об отсутствии TIER1 (или L1), как класса.

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

Очевидно, что по Gartner’у нужно добавить еще 2-3 десятка типов решений, но для Российских реалий и нашей нормативки и так выходит приличный перечень (за рамками стандартных «куплю СЗИ от НСД, МЭ, СОВ, антивирус и отстаньте»), на который можно будет официально ссылаться.

Чтобы не утомлять, приведу заключительный в заметке интересный момент, который как бы подсказывает ключевые процессы в SOC.

Можно долго улыбаться, но если посмотреть на схему, то она на самом деле перекликается с «настоящими» процессами SOC. Кроме того, действуя по ней, вы уж точно не упустите никаких «формальных» процедур.  

Выводы.

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

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

Используя ГОСТ можно наглядно доказывать свою позицию (регулятору, руководству) по выстраиванию процессов SOC. А если сделать хитрость и взять его за основу и дорисовать свои собственные элементы – то возможно получить работающий инструмент именно в ваших реалиях.

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

Я надеюсь, что этим документом взято начало целой серии полезных практических материалов по сложной теме КИИ, методическое обеспечение которой, мягко говоря, сильно отстает от реальных потребностей рынка. Не знаю, как вам, а мне заметна правильная тенденция выпуска практических документов под эгидой регуляторов, в том числе с идеями из зарубежных стандартов. Наступит ли закат построения лучших практик ИБ в России по блогам? Честно, не думаю ;)

Оставайтесь на светлой стороне.

Вечерние посиделки, ТОП 2019. То ли еще будет в 2020!

Как и обещал, друзья, делюсь наиболее интересными событиями из разряда «душевных» пика делового и конца календарного 2019 сезона. Получилась великолепная пятерка. Количество красивой цифрой 5, между тем, случайно нарисовалось. Кстати, самое-самое вкусное – в конце. Не переключайтесь J

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

1. X5Tech Future Night, ноябрь 2019

Зайду, пожалуй, с козырей, дважды подмухлевав. Во-первых, данное мероприятие на самом деле про технологии в целом и их применение в ритейле в частности, а не узко поИБэ. Как озаглавили организаторы – «это диалог о будущем и настоящем цифровизации бизнеса, впервые X5 Retail Group собрал на одной площадке визионеров, выявляющих будущие тренды уже сегодня, и экспертов-практиков, активно внедряющих самые современные технологии». Во-вторых, оно было организовано не кулуарно, а с настоящим размахом, что не помешало чувствовать себя свободнее, чем на большинстве официальных конференций. Мне понравился сам подход, местами весьма смелый. Классический доклад, по сути, был всего один – от футуролога Хироши Хори (Hakuhodo Institute of Life and Living, Япония), он рассказывал о мире будущего, о моделях поведения людей и о том, что очень скоро мы все будем жить в одном из четырех типов стандартизированных городов. Я со многим не согласен, прежде всего с тем, что это наступит в обозримой перспективе, но послушать было интересно. Остальная часть деловой программы состояла из живых разговоров с неприкрытым троллингом и настоящих баттлов действительно серьезных ТОПов: с ограниченным временем, четким заданием, жесткими правилами. Это было по истине шоу для зрителей, заметно, что спикеры готовились, прослеживался главный фокус – все ради аудитории. Стоит ли говорить, что ни о какой рекламе собственных продуктов не было и речи. Все приведенные примеры логично служили поддержкой отстаиваемых спикерами аргументов. В кулуарах встречались крайне общительные коллеги, всем спикерам также можно было свободно позадавать вопросы. Возможно, смелость вызвана отсутствием регуляторов – ну и пусть. Завершилась «ночь будущего» концертом кавер-группы и оранием рок-хитов. С последним и у нас в отрасли, вроде как, проблем нет. Итог банален: любое мероприятие должно иметь свою цель. Мне, как в данном случае потребителю хлеба и зрелищ, очень импонирует продуманность, подготовка и забота о слушателях. Ради тебя приложено немало сил, и это приятно ощущать. Как в этом всем (и нужно ли) совмещать профит для организаторов и спонсоров – вопрос отдельный, оставим за скобками.

2. R-Vision R-meetup, октябрь 2019

(фото - с сайта мероприятия)

Команда R-Vision вообще мне очень импонирует славным коллективом и интересными проектами. В октябре 2019 года ребята провели митап по хайповой теме «Практика реализации требований 187-ФЗ О безопасности КИИ». Как утверждается, это был эдакий первый пробный шар и формат обещает быть серийным. Главная цель - обмен опытом и получение полезных сведений по актуальным темам информационной безопасности. Среди приглашенных гостей на этот раз были представители всех «заинтересованных сторон»: вендоры, интеграторы, заказчики. Пришли даже регуляторы, не взирая на поздний час. Слушателей порадовали массой практики, откровениями, голосовалками с пророй неожиданными результатами. Да, теория (особенно законодательная) сильно расходится с практикой, это в очередной раз стало не секретом. Но даже в таких условиях работу безопасника можно и нужно конструктивизировать и автоматизировать. В этом очень большой спрос, тем отраднее, что мы, #gardatech, активно помогаем коллегам в данных направлениях. Народу было не сильно много, что только добавило атмосферности и непринужденности. Лично для меня оказались интересными не только жизненные практики «не под запись» коллег на обязательном фуршет-брейке, но и крайне продуктивный диалог с регуляторами. Не тот самый постановочный «диалог», который на больших сценах, а натуральный и без красителей. Желаю удачи ребятам из R-Vision, так держать! Обязательно поучаствую и впредь, спасибо за приглашение рассказать что-нибудь интересное в следующий раз, принимается J

3. Встреча сообщества "Кибербезопасность АСУ ТП" / RUSCADASEC, ноябрь 2019

(фото – из группы FB)

    Да, ИБ АСУТП – не область мои глубоких изысканий, однако, на практике встречаешься с этой темой периодически. Но не только лишь поэтому, но, чтобы приятно провести время за разговорами с друзьями и обрести новых, я отправился на очередную встречу сообщества RuScadaSec. Антон, спасибо, что позвал, было интересно! Официальная вывеска гласит: «Знакомство, обмен опытом, обсуждение идей, планов, историй, новостей по безопасности АСУ ТП в неформальной обстановке за кружкой пива!» Все оказалось ровно так же круто, как звучит - подтверждаю. Я тоже считаю, что тема КИИ должна сблизить тех, что давно занимается «реальной безопасностью» АСУТП (не взирая на комплаенс) и «остальных» безопасников из всего «рыночного квартета»: вендоры, интеграторы, заказчики, регуляторы. На мероприятии лично для меня были развеяны некоторые мифы о суровости хардкорной промышленной ИБ. Кроме того, хит-парад факапов пополнился забавными историями из цикла «кто в армии служил, тот в цирке не смеётся». Парни, вы уж точно делаете ту самую важнейшую работу для людей, это факт. Я уж молчу про тьму, оказывается, общих знакомых, воспоминания зеленой юности и эмоции «ах, ты теперь здесь!» Ну и узость темы (равно как для некоторых официальных мероприятий) играет свою положительную роль: все-таки фокусной практики больше, всегда легче идти по заданному вектору, не так ли. Я уверен, что количество эдаких расширенных «тим-билдингов» обеспечит так необходимое качество коммуникаций и повысит продуктивность нашей общей работы. Так, где уж там достигается наибольшее число договоренностей?

    4. Суд ИБ-присяжных, ноябрь 2019

    От креативного и неповторимого Олега Седова можно ждать подвоха с любой стороныJ Но даже учитывая личность организатора, название и анонс интригуют даже самых прожжённых ИБ-шников: «В формате суда ИБ-присяжных мы рассмотрим два дела с двумя летальными исходами. Дело №1: Истец Дмитрий Мананников «Имеет ли ИБ право на ошибку? Дело №2: Истец Игорь Залевский «Могут ли сотрудники службы ИБ, получив аутентификационные данные от почты злоумышленника, воспользоваться этим?» Если вы не имели удовольствия посетить судебное заседание, наслаждаясь чашечкой кофе, стаканом импортного сидра или кружечкой пенного марки «в Чехии не умеют варить пиво», считайте, вы и судов не знаете. Задумка – просто потрясающая. Представляете, если в следующий раз на скамью подсудимых, просто господи, посадить регуляторов? Да бросьте, даже просто свидетелями вызвать. Будет аншлаг, гарантирую. Приятно было видеть, что все без исключения стороны процессов реально готовились. Как они потом признавались в личных беседах – даже не один день. Что лишний раз подтверждает тезис о заранее четком определении целей и направленности мероприятия. Тогда и аудитория отплатит благодарностью. Подбор судей и присяжных - «мастодонтов» отрасли (некоторые с регулярным опытом участия в настоящих судах) также не оставляет ни единого шанса на провал. Некоторые профессиональные комментарии и «одергивания» сторон и вовсе разойдутся на цитаты. Между тем, споры внутри процессов разыгрывались нешуточные и порой градус напряжения даже был слишком высок. Заданные темы, кстати, были огого с каких подвохом. Честно, на некоторые вещи теперь посмотрел под новым углом. Ну и не обошлось без эдаких мини «coming out», которые никогда не услышишь на официальных мероприятиях. Формату – быть. Запомните, скоро потесним скучные домохозяйкины шоу на ТВ J

    5. Посиделки #ПоИБэ, вся осень 2019

(фото – канал группы)

  Без ложного лицемерия: last, but not least. Сообщество #Поибэшечка, созданное Львом Палеем, на мой скромный взгляд, обречено на успех. Идея гениальна и проста: нашему брату остро не хватает простых понятных инструментов, лайфхаков, чеклистов, опыта старших по званию коллег. Без буллшита, только польза, прокачка навыков, честный и прямой фидбек, здоровый троллинг и, конечно, живое общение. Этой осенью состоялось уже 3 душевных очных встречи, из которых я, увы, успел побывать лишь на одной. Да, это надо прочувствовать. Доклады здесь короткие и посвящены какой-нибудь одной простой задаче. Главное условие – чтобы знания и инструменты сразу же могли идти в практику, никакой теории. Более того - за неосторожный шепот с названием вендора или продукта полагается наказание в виде «штрафной». Учитывая барный формат посиделок и некоторое количество обязательно выпитого, каждая штрафная, что называется, уже на счету. Кроме докладов (да их и докладами не назовешь, это скорее и есть настоящие мастер-классы) есть еще 3 формата, которые как я и весь пост намекаю, нацелены на «захват» аудитории. Первый - Сценка - представляет собой самую настоящую разыгранную историю, для примера – «вендор-заказчик», как в театре, весьма забавно и тонко. Второй формат – Баттл. Довольно безжалостный и местами на грани. От этого и сильно захватывающий. Да, к нему нужно серьезно готовиться: просто хорошо разбираясь в теме, его не выиграть. Последние два формата – Блиц и Стендап. На мой взгляд – это самые сложные истории, ведь нужно много импровизировать и уж тут даже самая серьезная подготовка может не выручить, нужно иметь хороший кругозор и тренировать в себе определенные навыки. Тем интереснее будет принять, все-таки, этот вызов. По всем форматам скажу одно: это крайне полезный опыт. Согласитесь, не так много задач в жизни, за факап по которым вы рискуете всего лишь хлопнуть очередную «штрафную» хорошего напитка. Словом, шикарная инициатива, желаю всестороннего ее развития в новом году!

   Подводя итог, хотелось бы подчеркнуть важность ламповых комьюнити инициатив для нашей родной отрасли поИБэ. Участие в них – это не только шанс поговорить без галстуков и уж тем более не просто повод сходить в бар, но и получить новый профессиональный опыт, обзавестись друзьями, а также решить самые настоящие бизнес-задачи, поверьте. Все это дорого стоит. Гораздо дороже той стоимости «затак», за которую их организуют коллеги. Спасибо вам за это и удачи в новом 2020!

   В заключении хочу отметить, что были приглашения на еще очень много интересных мероприятий из разряда «вечерних посиделок» совершенно на разные ИБ-темы. Всего, увы, не охватишь. Что ж, обязательно увидимся и оценим в другой раз. Ведь для чего все делается, если не ради человеческих ощущений и впечатлений. До новых встреч!

Оставайтесь на светлой стороне.

SOC Forum. Ну, давай, расскажи мне про смерть конференций.

Ну что, отгремело одно из знаковых мероприятий в отрасли ИБ - двухдневный SOC Forum 2019, версии v5. Каюсь, я посетил не все предыдущие, но где был – неизменно куча народа. Конечно, можно пенять на маленькое помещение, очевидно, следующий этап – снять Крокус. Но есть и другая метрика – по личным ощущениям на мероприятии были реально ВСЕ. Такое количество встреч с коллегами, даже заядлыми домоседами, я давно не припомню. Как всегда – множество рабочих контактов, успешно обсужденных насущных вопросов, которые в «этих ваших офисах» решаются со скрипом. Всем был искренне рад, повспоминали молодость. Сегодня расскажу о тенденциях, лучших находках организаторов и новых форматах.

Кстати, аккурат к SOC Forum совместно с AntiMalware.ru выпустили первое публичное сравнение коммерческих провайдеров SOC. Прошу любить и жаловать.

Начнем с регуляторов. Всегда же заходит J. Есть мнение, что «все ходят на регуляторов, они обеспечивают явку и успех мероприятия». Да, у нас всегда трепет перед ними, так повелось. И я уверен, если устроить голосовалку, каждый раз ответ будет «да, конечно, зовите побольше регуляторов!». Однако, ни один мой собеседник после «гос-сессии» не признался, что получил удовольствие. Топ мнений разделились между «и так понятно, что будет только хуже» и «ничего нового не узнал». К счастью, вариантов альтернативных занятий было достаточно.

«И я там был» (с). Само собой, Гарда не могла пропустить форум и мы традиционно радовали посетителей нашего стенда вкусняшками, подарками, а так же рассказывали про самые горячие новинки. Да, технологии у нас по-прежнему - огонь, ведь мы не делаем скучные вещи, ну или почти J Кроме стенда мой коллега, Дмитрий Горлянский, делал интересный доклад про наше NTA решение «Гарда Монитор».

Контент в целом порадовал, даже местами превзошел ожидания. Доклады о реальных кейсах из уст заказчиков совместно с поставщиками - всегда редкость, а на SOC Forum 2019 их было даже несколько. Вообще дижухи и презентаций результатов было много, а уж воркшопы и мини-баттл в стиле CTF – и вовсе целиком про практику.

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

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

Оставайтесь на светлой стороне.

Просвещение, баттлы, конкурс красоты.

Сегодня будет пост-размышление о мире, добрых делах и красоте. Читайте до конца, там – бонус – ссылка на красоту J. Я убежден, что безопасность – это то, что объединяет каждого. В уже давно цифровом мире мы ежечасно совершаем значимые для нас операции и манкируем элементарными правилами. При несоблюдении, на самом деле, элементарных правил кибергигиены можно нажить себе вполне ощутимые последствия. И они будут не самыми приятными. И в том большая заслуга отдельных уважаемых коллег, что они популяризируют нашу непростую область, перекладывая ее в сказки, короткие чек-листы, правила, написанные лаконично и доступно. Знаете, как иногда говорят «больше боссы» или простые обыватели: «А теперь переведи ос своего, компьютерного, на наш, человеческий». Некоторые регуляторы стали выпускать полезные статьи и даже мультфильмы на актуальные темы кибербезопасности. Что, однозначно, позитивно.

Не знаю, как все, но я однозначно горжусь тем, чем занимаюсь. Везде случаются отдельные нюансы, каждый должен «зарабатывать на хлеб», но пока пользы ощутимо больше. Осмелюсь предположить, что общество в целом в плюсе даже просто от рекламного пиара. А уж когда мы видим по-настоящему жаркие дискуссии – это целое вишневое дерево на сладком десерте. Примерами могут служить как широко освещаемые события, например, недавний «спор» Г. Грефа и Э. Набиуллиной. По правде говоря, как бы я не относился к разного рода топ-экспертам, рациональное зерно у них всегда присутствует. Они аргументированно отстаивают свою позицию и даже если ты не согласен в целом, местами понимаешь, «hmm, makes sense».

Так вот, тема разного рода баттлов – супер вещь. Вместе с тем требует подготовки, определения четких правил, осмелюсь даже сказать сценария. В противном случае людям очень сложно в пылу борьбы не начать использовать запрещенные приемы, отключать этику или переходить на личности. Такие вещи не красят шоу. А ведь любой публичный баттл делается исключительно и для аудитории, иначе можно и вдвоем в кафе посидеть. Толпа, безусловно, жаждет крови, но ее должно быть в меру. В нашей полезной, но ой какой непростой во всех отношениях сфере, очень важно находить баланс между профессиональной дискуссией и поиском правых/виноватых. Такому, уверен, даже учат на специальных тренингах. Давайте просто будем стараться направлять любой избыток энергии в полезное обществу русло. Ведь в этом и есть вся цель профессии, разве не так?

И красивые девушки - отличный пример такого русла! Уже неоднократно мы с коллегами отмечали, что число представительниц прекрасного пола в нашей профессии растет, что не может не радовать. Коллеги из CIS организовали потрясающий конкурс «МИСС CIS». Голосуем за самых прекрасных дам из лучшей отрасли на свете! Я – уже.

Оставайтесь на светлой стороне.

ГосСОПКА - все? Разбор приказов ФСБ 281 и 282.

В заголовке - не приговор (всЁ) ГосСОПКЕ, а местоимение всЕ. Я о том, что все долги приказы ФСБ касательно 187-ФЗ "О безопасности критической информационной инфраструктуры РФ" похоже вышли из под пера регулятора. Как и предыдущие, новые приказы ФСБ небольшие: 6 и 9 страниц, для сравнения 239 приказ ФСТЭК - 32 страницы. На момент написания заметки не удалось их найти на официальных сайтах, наверное, это вопрос времени.

Итак, приказы:
Приказ ФСБ России от 19.06.2019 № 281 «Об утверждении Порядка, технических условий установки и эксплуатации средств, предназначенных для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты, за исключением средств, предназначенных для поиска признаков компьютерных атак в сетях электросвязи, используемых для организации взаимодействия объектов критической информационной инфраструктуры Российской Федерации»

http://publication.pravo.gov.ru/Document/View/0001201907170025
и

Приказ ФСБ России от 19.06.2019 № 282 «Об утверждении Порядка информирования ФСБ России о компьютерных инцидентах, реагирования на них, принятия мер по ликвидации последствий компьютерных атак, проведенных в отношении значимых объектов критической информационной инфраструктуры Российской Федерации».

http://publication.pravo.gov.ru/Document/View/0001201907170027

Внимательно читайте

Советую при изучении приказов внимательно смотреть на наличие слова "значимый" перед "объект КИИ". Например 281 приказ - для всех, а в 282 явно указано "значимых". Но по тексту 282 приказа слово "значимый" порой то теряется, то появляется. Прочтите пункт 2 приказа 282 А в 4-м пункте так вообще сроки явно установлены для обоих типов объектов. Поэтому я бы не стал расслабляться и примерял оба приказа на себя, даже если у вас нет значимых объектов.

Цифры

• 45 дней - за такой срок до начала установки Средств СОПКА субъект КИИ должен направить на согласование в ФСБ схему их подключения. 
• еще 45 дней - есть после этого у ФСБ чтобы согласовать или нет схему.
• 5 дней - в такой срок после успешного согласования субъекты КИИ, поднадзорные Банку России, должны отправить сведения и туда.
• 5 дней - столько есть на уведомление при внесении изменений.
• 5 дней - срок уведомления НКЦКИ о вводе Средств СОПКА в эксплуатацию.
• 24х7х365 - именно такой режим безотказной работы Средств СОПКА субъект КИИ обязан соблюдать.
• 3 часа - для ЗНАЧИМЫХ объектов есть с момента обнаружения инцидента, чтобы передать сведения о нем в НКЦКИ.
• 24 часа - для ИНЫХ объектов есть с момента обнаружения инцидента, чтобы передать сведения о нем в НКЦКИ.
• 90 дней - есть у владельцев значимых объектов на подготовку плана реагирования на инциденты.
• 48 часов - есть у владельцев значимых объектах на доклад в ФСБ об успешной ликвидации последствий инцидента.

Интересные факты

• Субъект КИИ, поднадзорный Банку России, обязан взаимодействовать с ФСБ и только, как кажется по тексту, "факультативно" с ФинЦЕРТ. Это обидно.
• Помимо схемы установки Средств СОПКА в ФСБ нужно пофамильно предоставить ответственных должностных лиц, вот это уже интересно.
• Настраивать и обслуживать Средства СОПКА может либо субъект КИИ самостоятельно, либо с привлечением лицензиата ФСТЭК (конкретные виды лицензий пункты не указаны).
• Прописаны условия привлечения ФСБ России к реагированию на инциденты в случае необходимости, которая никак четко не определяется. Например, должен быть согласован план совместного реагирования, на согласование у ФСБ есть 30 дней.
• Владельцы значимых объектов обязаны не реже 1 раза в год проводить тренировки по отработке плана реагирования на инциденты. И это первое явное упоминание киберучений в отечественных НПА.

Оставайтесь на светлой стороне.

UPD: добавил ссылки на сами приказы.