Салют, спасибо за комментарии, можете дать детали, что не адаптировано именно? Также тут нет видения интегратора или вендора, тут скорее описаны реалии практической значимости и собственное видение, в призме практик, которые используются и применяются. Был бы рад услышать ваши комментарии по тому, что "на самом деле происходит в эксплуатации" и чего именно. В любом случае все понимают, что в реальной практике без базиса не обойтись и это именно то, с чего происходит основа и статья не посвящена отдельной теме, а именно проблематике в общем формате. Я планирую далее описать свой опыт и видение ;)
Салют, спасибо за комментарии, стараюсь адаптироваться под стилистику площадки и поделиться своим опытом, также мне интересно писать ;)
Насчет диссертации, да - в процессе написания, в перечень РИНЦ и ВАК знаю, что не входит - скорее это для хобби и себя.
Источники моложе 5 лет конечно есть, если посмотреть другие мои статьи, то можно заметить свежие материалы. В данной статье я скорее делился материалом, который обработал и применил на практике. По актуальности темы - если говорить в плоскости практики - обычно это идея наложение методик на новые реалии, так как бизнес "шевелится" только по факту штрафов или утечек. По темам - их разнообразное количество.
Салют, спасибо за комментарии - "великий и ужасный русский язык", - буду рад если поправите на корректность, вдруг вы увидели что-то чему можете научить ;)
Приветствую, это к теме reverseeng — как я думаю речь идет про восстановление данных через кластера внутренних элементов, могу на досуге в лс скинуть пару интересных тем по этим вещам ;) А если быть честным, со стороны ИБ, — любые данные восстанавливаются, за исключением данных, которые затерты нулями по кластеру и применением специальных методов.
Приветствую, интересно описано, а есть что-то из собственной практики и видов обфускации, которые реально были применены и воздействовали от НДВ и/или reverseeng?
Отдельно хотел бы уточнить про контрольные суммы файлов и как идет предотвращение внедрения бит в потоки типа elf-файлов?
Интересует пример практики или ваше видение, — отдельное спасибо за детализацию и углубение)
Буду рад прочитать несколько интересных и опытных предотвращений эксплойтов, вне коммерческой тайны ;)
Приветствую, спасибо за ваш фидбек. Интересное замечание про алгоритм написания автоматизированных статей, — поизучаю на досуге и посмотрю на сколько он работает. Судя по запросам в "гугле" выдаются забавные моменты :)
Спасибо за комментарий, приятно пообщаться со знающим человеком ;)
Да, я понимаю этот момент, но по своему профилю стараюсь делать упор для «бизнеса» в процессе разработки. Так как «посмотрев» за границей, как работают ребятки — стало понятно, отчего и почему у нас в РФ идет копипаст)))
Я понимаю, что имеются другие типы уязвимостей от НДВ, НСД, теймплейтов и так далее, но OWASP TOP 10 был приведён в пример из за его популярности в сообществе, я думаю, что напишу отдельную статью по этой теме, которая касается уязвимостей ;)
Приветствую, спасибо за ваш фидбэк, по данной методологии SCRUM согласен, что именно так и проходит формат общения, где Product Owner и/или SCRUM-мастер выступают в роде ведущего. В статье описываются методология управления в том числе. Про SCRUM достаточно много статей, которы описывают процессы и передают опыт в формате оптимизации мощностей.
Приветствую, спасибо за ваш фидбэк, отвечу следующим образом: мы не рассматриваем защищенное ПО в конечном виде, а рассматриваем процесс безопасной разработки ПО, которая позволит выстроить процессы в организации.
Активы и пассивы организации взаимосвязаны, так как при изменении одного параметра изменяется соответствующий ему другой параметр, — например, так просчитывается амортизация сотрудника как ресурса в организации, либо же рентабельность, ликвидность продукта. Про рост, я бы сказал, что он происходит последовательно.
Приветствую, изначально в статье вводится базис для понимания какие есть типы АИС и что такое в итоге ИС, среда, включая информацию, которая в ней обрабатывается. На базе данных типов ИС и сред, вводится объяснение по какой причине стала прогрессировать разработка безопасного ПО и почему разрослось количество методов, средств — методологий разработки ПО. Также, вопрос данной статьи рассматривается в конкретном направлении и условиях, где OWASP TOP 10 является применимым для каждой из перечисленной ИС при безопасной разработке ПО, так как ненадежный софт может предоставить значительные проблемы в стадии разработки, эксплуатации и модернизации.
Также, отмечу, что в статье рассматривается только разработка ПО, методологии разработки и управления.
Отвечу на ваш комментарий:
Но в том же АСУТП есть много других компонентов, для которых OWASP не применим.
Что мы не рассматривали комплексный подход типа MLS для всей параллели ИБ, а только конкретное узкое место. Надеюсь, что ответил на вопрос, спасибо за ваш фидбэк ;)
Приветствую, возможно вы правы ;) Спасибо за фидбэк.
Но, все-же стоит обратить внимание, что не возможно в одной статье детально и развернуто описать каждый метод со стороны практики. Именно поэтому приводится сводный анализ в виде спецификации и методам их управления. Если честно, — постарался поделиться мыслями и рассказать про практический опыт, без абстрактных сущностей ;)
Приветствую, спасибо за детальные комментарии, хотел бы уточнить:
как долго данный формат сертификации/аттестации может проходить на практике? Имеется ввиду на базе указанного вами в контексте статьи, на базе указанного примера.
Приветствую, понравилась ваш подход, но хотел бы уточнить в большей степени практическую значимость по ряду вопросов (скорее всего примитивных, но необходимых для личного понимания) — где хотелось бы услышать ваше мнение/ответы:
что насчет применимости УК РФ по ЗИ субьекта, обьекта КИИ РФ на базе вашего примера, в плане ответственности в случае возникновения инцидента — если рекомендательные документы, без обязующих к выполнению НПА, были не рассмотрены организацией или были приняты на "свое усмотрение" ответственным лицом? Вопрос составлен при условии того, что "новизна" и "изменчивость" КИИ идут от 2018 года, где хотелось бы понимать практическую значимость, которую вы видите, а желательно прочитать ваши мысли в формате: как обезопасить ответственной лицо, даже в ситуации "общего" характера — при условии вашего опыта ;)
как можно минимизировать риски по БП для отдела ИБ не "ставя палки в колеса" бизнесу, в данном примере, если есть обязательные СЗИ и есть рекомендуемые в плане применимости на базе ДОУ (включаемые с категорированием информации по видам тайн, не рассматривая ГТ — как вы и указывали), включая уже упомянутую вами ИСПДн? Я понимаю, что все зависит от уровня ущерба по оценке возникновения риска — которые рассматриваются в отдельных ИС, включаемых в циклы процессной деятельности организации, но вопрос стоит вокруг изменений и нормативной базы в плане СЗИ в нынешних условиях применимости НКЦКИ ГосСОПКА, включая формат типизации на базе ПИБО, которая строится от модели нарушителя, атак и угроз.
что стоит делать, если СПО СЗИ/КСЗИ, которое было выбрано при перекрытии угроз на базе моделей и делегирования доступов нарушителей — дублирует действующий функционал друг друга с перекрытием и усложнением БП?
можно ли упростить всю "процессию" при условии применения самостоятельного решения в плане автоматизации БП организации и свести все к моделям распределения уровней значимости системы, такого типа как MLS? В вашем примере приведены данные в формате
Что касается использования СКЗИ, для организаций реализующих 1-ый уровень защиты, необходимо использовать сертифицированные ФСБ России СКЗИ. Для остальных организаций действует правило, согласно которому все используемые СКЗИ российского производства также должны быть сертифицированными.
— если вы рассматриваете данный пример, тогда каким образом строится формат применимости СПО, относительно БДУ ФСТЭК России, включая покрытие на базе моделей нарушителя, атак и угроз? Речь скорее не про построение моделей, а в плане применимости СЗИ и ее «обязательности».
как долго данный формат сертификации/аттестации может проходить на практике?
есть ли у вас какая-то методология по введению в промышленную эксплуатацию?
если финансовая организация использует СКЗИ российского производителя, то оно должно иметь сертификат ФСБ России.
— что насчет обязательного импортозамещения продуктов на рынке ИБ, включая рассматривание модели нарушителя, в которой иностранный софт, а также лица — являются «угрозой»?
ПС: спасибо за статью, приятно было ее прочитать и задать вам вопросы ;)
Приветствую, уточнение: вы имеете ввиду выстраивание процессов по ОИБ с покрытием функций ЗИ или же речь идет про формирование связей Эйлера в формате применимости? Спасибо
Приветствую, интересно получить ваши комментарии на пару вопросов:
что вы думаете насчёт практики оптимизации мощностей организации в плане координации отделов IT под отделами IS? Идёт речь не про коллаборацию, которую Вы описали, а именно контроль специалистов отделами ИБ (IS).
может ли решить указанную проблему применение CI/CD в формате делегирования ответственности на аутсорсинг при построение архитектуры на базе мощностей сторонней организации? Либо в формате безопасной разработки, как пример: ГОСТ Р 56939-2016. Как пример механизма по типовому БП: работа devops специалиста на выделенном сервере (не рассматривая КЗ и ВП) с применением QA, где можно поставить СПО для мониторинга? То есть вести циклическую разработку. Я понимаю, что в любых условиях на практике не реален цикл Дёминга, но все же ;)
Салют, спасибо за комментарии, можете дать детали, что не адаптировано именно?
Также тут нет видения интегратора или вендора, тут скорее описаны реалии практической значимости и собственное видение, в призме практик, которые используются и применяются. Был бы рад услышать ваши комментарии по тому, что "на самом деле происходит в эксплуатации" и чего именно. В любом случае все понимают, что в реальной практике без базиса не обойтись и это именно то, с чего происходит основа и статья не посвящена отдельной теме, а именно проблематике в общем формате. Я планирую далее описать свой опыт и видение ;)
Также, по CISSP:
Security and Risk Management
Asset Security
Security Architecture and Engineering
Communication and Network Security
Identity and Access Management
Security Assessment and Testing
Security Operations
Software Development Security
Салют, спасибо за комментарии, стараюсь адаптироваться под стилистику площадки и поделиться своим опытом, также мне интересно писать ;)
Насчет диссертации, да - в процессе написания, в перечень РИНЦ и ВАК знаю, что не входит - скорее это для хобби и себя.
Источники моложе 5 лет конечно есть, если посмотреть другие мои статьи, то можно заметить свежие материалы. В данной статье я скорее делился материалом, который обработал и применил на практике. По актуальности темы - если говорить в плоскости практики - обычно это идея наложение методик на новые реалии, так как бизнес "шевелится" только по факту штрафов или утечек. По темам - их разнообразное количество.
Салют - если бы SCIgen, но нет ;)
Если что то не понятно - могу обьяснить, с удовольствием.
Салют, спасибо за комментарии - "великий и ужасный русский язык", - буду рад если поправите на корректность, вдруг вы увидели что-то чему можете научить ;)
Приветствую, спасибо за комментарии, можете уточнить о чем конкретно речь идет? Был бы рад увидеть аргументы ;)
Салют saipr — а есть какой-нибудь интересный пример этого?
Приветствую, это к теме reverseeng — как я думаю речь идет про восстановление данных через кластера внутренних элементов, могу на досуге в лс скинуть пару интересных тем по этим вещам ;) А если быть честным, со стороны ИБ, — любые данные восстанавливаются, за исключением данных, которые затерты нулями по кластеру и применением специальных методов.
Приветствую, интересно описано, а есть что-то из собственной практики и видов обфускации, которые реально были применены и воздействовали от НДВ и/или reverseeng?
Отдельно хотел бы уточнить про контрольные суммы файлов и как идет предотвращение внедрения бит в потоки типа elf-файлов?
Интересует пример практики или ваше видение, — отдельное спасибо за детализацию и углубение)
Буду рад прочитать несколько интересных и опытных предотвращений эксплойтов, вне коммерческой тайны ;)
Приветствую, спасибо за ваш фидбек. Интересное замечание про алгоритм написания автоматизированных статей, — поизучаю на досуге и посмотрю на сколько он работает. Судя по запросам в "гугле" выдаются забавные моменты :)
Отвечая на ваш вопрос: нет.
Спасибо за комментарий, приятно пообщаться со знающим человеком ;)
Да, я понимаю этот момент, но по своему профилю стараюсь делать упор для «бизнеса» в процессе разработки. Так как «посмотрев» за границей, как работают ребятки — стало понятно, отчего и почему у нас в РФ идет копипаст)))
Я понимаю, что имеются другие типы уязвимостей от НДВ, НСД, теймплейтов и так далее, но OWASP TOP 10 был приведён в пример из за его популярности в сообществе, я думаю, что напишу отдельную статью по этой теме, которая касается уязвимостей ;)
Поддерживаю, посты написаны, ошибки исправлены ;) буду рад стать «Дедом Морозом», хочется в этот год закрыть его максимально позитивно!
Приветствую, спасибо за ваш фидбэк, по данной методологии SCRUM согласен, что именно так и проходит формат общения, где Product Owner и/или SCRUM-мастер выступают в роде ведущего. В статье описываются методология управления в том числе. Про SCRUM достаточно много статей, которы описывают процессы и передают опыт в формате оптимизации мощностей.
Приветствую, спасибо за ваш фидбэк, отвечу следующим образом: мы не рассматриваем защищенное ПО в конечном виде, а рассматриваем процесс безопасной разработки ПО, которая позволит выстроить процессы в организации.
Активы и пассивы организации взаимосвязаны, так как при изменении одного параметра изменяется соответствующий ему другой параметр, — например, так просчитывается амортизация сотрудника как ресурса в организации, либо же рентабельность, ликвидность продукта. Про рост, я бы сказал, что он происходит последовательно.
Приветствую, изначально в статье вводится базис для понимания какие есть типы АИС и что такое в итоге ИС, среда, включая информацию, которая в ней обрабатывается. На базе данных типов ИС и сред, вводится объяснение по какой причине стала прогрессировать разработка безопасного ПО и почему разрослось количество методов, средств — методологий разработки ПО. Также, вопрос данной статьи рассматривается в конкретном направлении и условиях, где OWASP TOP 10 является применимым для каждой из перечисленной ИС при безопасной разработке ПО, так как ненадежный софт может предоставить значительные проблемы в стадии разработки, эксплуатации и модернизации.
Также, отмечу, что в статье рассматривается только разработка ПО, методологии разработки и управления.
Отвечу на ваш комментарий:
Что мы не рассматривали комплексный подход типа MLS для всей параллели ИБ, а только конкретное узкое место. Надеюсь, что ответил на вопрос, спасибо за ваш фидбэк ;)
Приветствую, возможно вы правы ;) Спасибо за фидбэк.
Но, все-же стоит обратить внимание, что не возможно в одной статье детально и развернуто описать каждый метод со стороны практики. Именно поэтому приводится сводный анализ в виде спецификации и методам их управления. Если честно, — постарался поделиться мыслями и рассказать про практический опыт, без абстрактных сущностей ;)
Приветствую, спасибо за детальные комментарии, хотел бы уточнить:
Приветствую, понравилась ваш подход, но хотел бы уточнить в большей степени практическую значимость по ряду вопросов (скорее всего примитивных, но необходимых для личного понимания) — где хотелось бы услышать ваше мнение/ответы:
ПС: спасибо за статью, приятно было ее прочитать и задать вам вопросы ;)
Приветствую, интересно получить ваши комментарии на пару вопросов:
Приветствую, а что думаете насчёт применения теории надежности в практике и многоуровневым решёток безопасности?