Отправная точка создания системы, безопасной “by Design”

Александр Винявский
Технологический евангелист

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

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

Для создания по-настоящему защищенных систем существует идеология Secure by Design. Она предполагает, что мы начинаем думать о безопасности еще до начала разработки архитектуры.

Но что значит «думать» о безопасности? Для начала — понять, что конкретно она значит для вас и вашего проекта.

Что такое безопасность?

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

Значит, придется выбирать меры защиты. И если формальных требований от бизнеса нет — а часто они сводятся к «сделайте безопасно» — то эта задача ложится на плечи разработчиков. И велик риск выбрать не те меры, которые необходимы и достаточны, а например, те, которые хорошо знакомы. Ведь лучше делать, что хорошо знаешь?

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

Цели и предположения безопасности

Давайте сравним эти два понятия. Цели безопасности — это инвариантные свойства системы, которых вы хотите добиться, чтобы она безопасно функционировала в любых возможных сценариях использования (с поправкой на предположения безопасности). А предположения безопасности — это ограничения, которые вы накладываете на сценарии использования системы.

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

  • Данные через шлюз проходят только в одном направлении — из защищенной подсети в облако, при любых обстоятельствах.

И, например, такие предположения безопасности:

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

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

Подробнее про цели и предположения безопасности я расскажу в следующих постах.

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

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

Для создания по-настоящему защищенных систем существует идеология Secure by Design. Она предполагает, что мы начинаем думать о безопасности еще до начала разработки архитектуры.

Но что значит «думать» о безопасности? Для начала — понять, что конкретно она значит для вас и вашего проекта.

Что такое безопасность?

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

Значит, придется выбирать меры защиты. И если формальных требований от бизнеса нет — а часто они сводятся к «сделайте безопасно» — то эта задача ложится на плечи разработчиков. И велик риск выбрать не те меры, которые необходимы и достаточны, а например, те, которые хорошо знакомы. Ведь лучше делать, что хорошо знаешь?

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

Цели и предположения безопасности

Давайте сравним эти два понятия. Цели безопасности — это инвариантные свойства системы, которых вы хотите добиться, чтобы она безопасно функционировала в любых возможных сценариях использования (с поправкой на предположения безопасности). А предположения безопасности — это ограничения, которые вы накладываете на сценарии использования системы.

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

  • Данные через шлюз проходят только в одном направлении — из защищенной подсети в облако, при любых обстоятельствах.

И, например, такие предположения безопасности:

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

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

Подробнее про цели и предположения безопасности я расскажу в следующих постах.

Консультация по решению

Остались вопросы или требуется дополнительная информация по решению? Оставьте заявку на консультацию, и мы с вами свяжемся!

Задать вопрос

Отвечаем на самые популярные вопросы о KasperskyOS и решениях на ее основе

Перейти в FAQ
Мы используем файлы cookie, чтобы сделать работу с сайтом удобнее.
Продолжая находиться на сайте, вы соглашаетесь с этим. Подробную информацию о файлах cookie можно прочитать здесь.