В статье представляется исследование спецификации методов, средств и методологий безопасной разработки, которая принята на территории РФ, включая перенятый опыт от зарубежных коллег, "бестпрактик", канонов и иного рода вариатив, которые применяются в настоящее время.  Исследование рассматривается со стороны коммерческого сектора и самых эффективных форматов безопасной разработки. Исследование рассматривается с применением в практической части данных вариатив и их специфик в целом, и частном формате. Целью данной статьи является передача опыта и аналитика данных применяемых методологий, методов и средств разработки в защищенном исполнении. В статье представлен анализ, соответствующий разбор действующего рынка, законодательства, в части касающейся разработки информационных систем и сред в защищенном исполнении, которая именуются также как безопасная разработка, и которая с каждым днем набирает "критическую массу" популярности в различных отраслевых компаниях из-за ужесточения рекомендаций и требований регуляторов ИБ [1].  Также стоит отметить, что популярность безопасной разработки первоочередно связана с тем, что число рисков, инцидентов ИБ критически растет с каждым днем. Прогрессирующие злоумышленники стали понимать детально принципы работ организаций, которые подвергаются атакам, при этом им удается входить в группу доверенных пользователей из-за недостатка компетенций и сотрудников в данных компаниях. Также злоумышленники научились применять более совершенные средства, методы для организации вторжений, "эксплойтов" и иного, для получения конфиденциальной информации, мошеннических действий. Данной тематике уделена значительная часть профильных статей по ОИБ.  Данная статья базируется на принципах и процессах автоматизации ИС и сред организации, где рассматривается вопрос со стороны личной практики как руководителя, так и разработчика. В статье представлено практическое оценочное мнение и его эффективность. Частично статья касается вопроса со стороны OWASP TOP 10, но акцент на этом будет поставлен в последующих статьях. Стоит отметить, что не рассматривается практика сертификации, аттестации, выполнении требований опытных лабораторий, проектирования ПО по ПП РФ №608, включая приказ ФСТЭК России №55 и иных документов по безопасной разработке в данном направлении. Рассматривается формат представления универсальных характеристик разработки в безопасном исполнении, автоматизации, оптимизации, масштабируемости, адаптации БП (бизнес процесс), в формате ГОСТ Р 56939.  В коммерческом секторе РФ отсутствует установленное понятие для всех ветвей организации управления организации, в сфере прямо или косвенно касающихся IT и смежных с данными подразделений, такого как: ИС (информационная система) и среда. В том числе отсутствует понимание ее классификации в целом и частном порядке. В общепринятом представлении на рынке в потребительской сфере также отсутствует понимание построения структуры и непосредственно семантики работы ИС и сред. Данный общепринятый формат объясняется следующим образом, что методы, средства и методологии разработки по созданию, оптимизации, масштабируемости, итерационной интеграции, введению в промышленную эксплуатацию – каноничны, во всем промежутке времени, которые парраллелелись по различным специфичным и обособленным между собою направлениям с применением разного рода подходов и методов для их реализаций. В последствии чего стали возникать угрозы, риски и последствия инцидентов для организаций, которые занимались обработкой, хранением информации, в том числе остро возник вопрос по ОИБ (обеспечение ИБ) информации: целостности, доступности, конфиденциальности. Этот вопрос также будет разобран отдельно в следующих статьях, где стоит отметить, что важнейшим аспектом стало на сегодня ОИБ КИИ РФ, также отдельно взяло направление по оценке рисков и инцидентов, в формате СУИБ (система управления информационной безопасности) и многое другое. В последствии данных форматов и форм-факторов возник вопрос безопасной разработки в организациях, где направление стало развиваться в геометрической прогрессии и набирать экспоненциальные обороты.  Приведем ИС в автоматизированном исполнении по типам, которые имеются на сегодняшний день и в связи с которыми разрослись методы, средства и методологии их реализации в разработке, проектировании и прототипировании, а именно:  Исходя из приведенного формата стоит дать определение термина информация, применяемого в безопасной разработке, касательно АИС (автоматизированная информационная система) в отношении действующего законодательства РФ, а именно: Следовательно, информация обрабатывается, передается и хранится, следовательно она подвержена определенным рискам со стороны злоумышленников и требуется обеспечение ее безопасности. Определим термин безопасность информации, который будем понимать как состояние уровня ее защищенности, которое обеспечивается сохранением качественных и количественных характеристик, а именно — целостности, доступности, конфиденциальности. Если рассматривать со стороны IT-сферы, то ИС обеспечивает: сбор, хранение, обработку, поиск, оптимизацию, масштабируемость, адаптацию, — то есть представление этой самой информации, которая применяется во время принятия управленческих решений любого рода в организации.  Отметим, что в следствии сбора и обработки информационных данных, последующего воссоздания, воздействия и изменения информации — на ней отражается политика взаимодействия процессов анализа и синтеза, представляемая обобщением организационных, технологических, технических, программно-аппаратных и информационных средств, и методов. Данные формы объединены в ИС и среды с целью их архивного сбора, хранения, обработки и выдачи информации для выполнения опосредованных функций и политик внутри, и вне организации.  С точки зрения ФЗ РФ №149 с изменениями и дополнениями, приводится следующее определение, такое как: «Информационная система – это совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств». Следовательно, отметим, что ИС представляется как прикладная подсистема, которая ориентирована на сбор, хранение, поиск и обработку текстовой или фактографической информации, работающая в режиме диалога с пользователем. Далее отметим универсальные характеристики для безопасной разработки ИС, такие как: Под спецификацией методологии понимается — объединение перечня средств и методов, применяющихся в специфике деятельности организации, со стороны теории и практики разработки, включая прототипирование. Методологией является формат объединения методов, средств и технологий, применяющихся во время всего жизненного цикла процесса разработки и прототипирования ПО в организации. Данный формат является совокупностью практически выработанного и действующего формата в узконаправленной специфике организации для всей программно-аппаратной части и комплекса в целом. Следовательно стоит отметить, что также под методологией безопасной разработки ИС понимается организация процессов прототипирования и выстраивания ИС и сред, таких как: обеспечения управления процессами для гарантированного выполнения ТТ, ТЗ и реорганизации процессов [6-10]. Приведем список-перечень задач для достижения обеспечения действенности методологии безопасной разработки ИС и среды, состоящей из:  Целью методологии является присвоение рамок конечного функционирования и бесперебойной работоспособности АИС по целевым и первоочередным нуждам организации. В реализации АИС применяются специализированные подсистемы ИБ для формирования средств и методов разработки и прототипирования посредством политик ИБ организации в СУИБ. Данные политики представляются в виде списка-перечня определенных действий для персонала, согласно определенной технологической базы и функционирования данных систем в настоящем, и будущем времени при использовании в промышленной эксплуатации. Опираясь на сводную классификацию проектной части работы Одинцова И.О.: "Профессиональное программирование. Системный подход", следует выделить:  Следует отметить, что приведенные методологии позволяют обеспечить безопасную разработку в организации по всем БП, что в свою очередь облегчит функционирование организации и управления кадровым составом, а это позволить повысить рентабельность и ликвидность конечного продукта. Данные форматы являются опосредованными и целостным, где позволят предотвратить методы и меры по OWASP TOP 10, что снизит риски и шансы возникновения инцидентов, а также их расследований по семейству ISO/IEK 27000.  Исходя из приведенных методологий и адекватного подхода руководящего состава можно сэкономить финансы организации, а также оптимизировать все процессы внутри и вне организации, что также относится к выполнению рекомендаций и требований регуляторов в ИБ. Если рассматривать вопрос со стороны противодействия злоумышленникам, — это также позволит минимизировать все возможные риски конечного продукта, но есть обратная сторона "медали", когда "бизнес" делает упор на скорость и принимая критичные риски для продукта, что в свою очередь показывает нынешнюю практику разработки продуктов на рынке РФ. Отмечу, что иностранные коллеги привыкли ставить "во главу" — ИБ и минимизацию рисков связанных с утечкой конфиденциальной информации на всех этапах жизненных циклов. По описанному формату имеются определенные принципы при выборе методологий в организациях для разработки и прототипирования ПО. Следовательно, первоочередно стоит привести классическую (каноническую, монументальную) методологию, которая применяется исходя из наличия следующих принципов, таких как:  Отметим, что данный формат является конечным и применимым для безопасной разработки со стороны конечных кейсов и задач, которые стоят перед разработчиками. Но у данного формата могут возникнуть специфичные проблемы при масштабировании и адаптации, которые в значительной степени будут влиять на финансы организации. Приведенная методология является популярной по рынку РФ, а также практичной при разовых работах с определенными подрядчиками, которая рассчитана на реализацию продукта в конечном виде и без формата поддержания далее. Такой формат является наиболее деструктивным для разработки долгосрочных продуктов, так как не поддерживается пролонгирование действий по ОИБ в системах и подсистемах продукта и не позволяет контролировать в полной мере риски организации, с учетом выполнения требований и рекомендаций регуляторов ИБ.  Приведем далее более гибкую адаптивную методологию, которая применяется по следующим принципам, таким как:  Приведенная методология позволяет спрогнозировать разностороннюю вариативность при разработки и прототипировании продукта, исходя из общего формата различных пользовательских кейсов, в том числе со стороны злоумышленник по типу: "а как бы это сделал я?". Методология позволяет предопределить возможные вариативные изменения в процессе разработки и контролировать итерационность получаемого продукта, что позволяет "бизнесу" контролировать риски, в том числе со стороны финансирования организацией. Отмечу, что приведенные принципы схожи с возможностью изменения продукта исходя из метрик при анализе для "бизнеса", что позволяет в процессе разработки контролировать все жизненные циклы и процессы версионности продукта, в том числе монетизирования. Этот формат подходит для долгосрочных продуктов, которым необходимо иметь возможность постоянной монетизации и частично быть конкурентноспособными исходя из максимизации перекрытия спроса — предложением [12].  Следует предоставить и разобрать самые признанные и распространённые манифесты для представления гибкой безопасной разработки ПО, таких видов как: Отмечу, что данные манифесты являются применимыми, но не всегда корректно, так как имеется практика введения только положительных методов из них, а не полноценного формата контроля и управления, где руководящий состав организации считает, что это будет наиболее эффективно, нежели чем процесс полноценной интеграции конкреной системы, что приводит к не корректному взаимодействию внутри команды и процесса разработки — дающего только отрицательный характер влияния на "бизнес". Для безопасной разработки ПО считаются важными данные аспекты методологии, управления, разработки и проектирования, так как они позволяют решить подавляющую часть проблем связанных с рисками и инцидентами ИБ, в том числе выполнить и перекрыть требования, и рекомендации регуляторов ИБ и обезопасить конечный продукт, а также "бизнес". В том числе учитываются специалисты по PenTest, DevSecOps и так далее, так как профильные специалисты с опытом смогу предоставить ОИБ организации [13-15]. Отметим, что все представление формации разработки, методологии вариативности и применимости методов относительно самой разработки, основываются на выборе поставленной целевой задачи. В том числе они рассматриваются на базе превентивных методов, средств, мер, включающих этапы непосредственной процессной реализации разрабатываемого продукта, включая календарный план-график работ, которые строятся на базе одной или нескольких методологий, которые описываются в данной статье.  В числе подавляющих методов по применимости наблюдается формирование соотношения качества и методов разработки, относительно показателей и выходных характеристик продукта. Данные форм-факторы показателей зависят от выбранных специалистов в разработке, включая безопасную разработку. Данные показатели строятся на уровне определения и формирования показателей на базе компетенций, опыта и соответствующих навыков, относительно уже имеющихся процессов в разработке продукта и его проектирования, в том числе. Приведенные методологии дают понимание их итерационной этапности и спецификации реализации разработки, проектирования, изменчивости продукта. Данный формат также рассматривается со стороны управления, коррелирования, масштабирования, оптимизации и адаптивности в целом и частном порядке, относительно сводных параметров в реализуемой системе. Отметим, что каждая политика, методика, методология, в том числе превентивные средства достижения поставленной цели, учитывая применяемые технологии имеют свою спецификацию определенного рода реализации и изменчивости. Данный форм-фактор гарантирует, при надлежащем контроле, повышение качественных и количественных показателей итогового продукта. Также стоит досконально выбирать этапы реализации и семантику политик действий в нескольких случай для контроля модели поведения разработчиков, в формате просчета их амортизации, так как от этого зависит подавляющая часть всей разработки и проектирования в целом. В том числе приведенные форматы позволяют контролировать ввод в промышленную эксплуатацию и обучения кадрового состава по использованию и применимости, впоследствии сопровождения реализуемого продукта. Важнейшим аспектом при такой деятельности является — формализации ТЗ, менеджмента управления и ТТ к продукту. По факту поступления в работу поставленных задач к разработчикам, прорабатывается их соответствующая детализация, формализация и верификация, относительно целевых нужд под проектирование и разработку ПО. Что в том числе позволяет просчитывать показатели адекватности, интерпретации моделей поведения, заполнения, разнородности, ликвидности, рентабельности, вариативности изменчивости процессов и тому подобное, что непосредственно коррелируется по совокупным метрикам посредством специалистов определенного рода и перечня, типа Product Owner.  Следовательно, в основе своей имеет место быть факт разрастания управленческого состава, что в последствии приводит к регламентации политик определенных действий, — типа ОРД (организационно-распорядительной документации) и внедрение определенных методологии в зависимости от уровня применения в менеджменте организации, а также средств достижения цели. То есть на сегодняшний день ситуация выглядит следующим образом с безопасной разработкой: не все моменты согласуются между обеими сторонами, а впоследствии уже только оптимизируются при рабочем процессе, где применяются менее оптимальные решения, нежели чем применять изначально формирование моделей поведения на базе приведенных методологий выше. Стоит отметить, что разработка и проектирование ПО при безопасной разработке основывается на базе функциональности ИС и совокупных сред, спроектированных относительно конечного ТТ и ТЗ. Также не мало важно понимание руководящего состава организации в обоснованности и целях безопасной разработке, где весомым показателем в данной ситуации являются оценочные метрики бизнеса в отношении рисков, которые фокусируются на целевых функциях ПО для монетизации. Данные функции разрабатываются и интерпретируются на вывод в необходимом количественном и качественном формате сведений, посредством представленных систем и подсистем в СУИБ, а не в процессе их верификационного построения.  В статье приведены конечные форматы смежных политик ИБ на базе методологий безопасной разработки ПО, включая методов и средств управления, включая оценочные метрики бизнеса под определенными видами нагрузок, стрессовых режимов по БП, а также в виде количественных и качественных характеристик обрабатываемой информации.  В статье описаны методологии безопасной разработки, которые зависят в полной мере от применяемого режима работы в организации, включая формации управленческих методологий. Рассмотрена вариативность методологий безопасной разработки относительно ИС и сред, где достигнут результат приведения практических особенностей и политик взаимодействий между управленческими методологиями, а также методами и средствами прототипирования, разработки, что показывает в свою очередь современные представления обеспечения безопасной разработки.  Приведенные методологии безопасной разработки могут предоставить организациям увеличение прибыли, контроль версионности, предотвращение вторжений, минимизаций рисков и обеспечить доверенный уровень среди своих пользователей, что поднимет активы и пассивы организации. В заключении стоит соотнести версионность непосредственной разработки и вывода в промышленную эксплуатацию, в отношении политик представления соответствия цена-качество, так как от этого зависит напрямую основополагающая часть реализации АИС, в части касающейся разработки и прототипирования ПО, то есть всех базовых и второстепенных БП, включая соответствующее сопровождение, обучение персонала и смежных методов с данными форматами. P.S.: если ставите минус, прокомментируйте, пожалуйста, дабы в будущем мне не допускать подобных ошибок. [1] Федеральный закон «Об информации, информационных технологиях и защите информации» № 149 — ФЗ от 27 июля 2006 года;
[2] ГОСТ Р 6.30-2003 «Унифицированная система организационно-распорядительной документации»;
[3] ГОСТ Р 7.0.8.-2013 "Делопроизводство и архивное дело — Термины и определения";
[4] ГОСТ 6.10.4-84 «Придание юридической силы документам на машинном носителе и машинограмме, созданным средствами вычислительной техники»;
[5] ГОСТ 6.10.5-87 «Унифицированные системы документации. Требования к построению формуляра-образца»;
[6] Доктрина информационной безопасности;
[7] Федеральный закон от 21 июля 1993 года №5485-1«О государственной тайне»;
[8] «О закрытом административно-территориальном образовании»;
[9] Астахова Л.В. Теория информационной безопасности и методология защиты информации: методическое пособие / Л.В. Астахова. – Челябинск: Изд-во ЮУрГУ, 2007. – 359 с.;
[11] Юдин, Э.Г. Методология науки. Системность. Деятельность / Э.Г. Юдин. – М.: Эдиториал УРСС, 1997. – 246 с.;
[12] Князева Т. Отечественные системы автоматизации делопроизводства;
[13] Комарова А.В., Менщиков А.А, Коробейников А.Г. Анализ и сравнение алгоритмов электронной цифровой подписи ГОСТ Р 34.10-1994, ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012// Вопросы кибербезопасности. 2016. № 1 (19). С. 51-56;
[14] Боровский А. С., Ряполова Е. И… Построение модели системы защиты в облачных технологиях на основе многоагентного подхода с использованием автоматной модели;
[15] Захаренков А.И., Бутусов И.В., Романов А.А., Степень доверенности программно-аппаратных средств как показатель качества замещения импорта // Вопросы кибербезопасности. 2017. № 4 (22). С. 2-9. BISO, DevSecOps, AppSec