Bpm решения

Аннотация

В статье представляется исследование спецификации действующей нормативно-правовой базы РФ для СЭД (системы электронного документооборота) в автоматизированном исполнении, действующей на рынке РФ в плане применимости к ЭП, на базе ФЗ РФ 63. Исследование рассматривается как в коммерческом секторе, так и в бюджетных образованиях. Представляется применение автоматизации СЭД в практическом формате со сводными спецификациями в целом и частном аспекте ПИБО (политике информационной безопасности организации), включая изучение и разбор действующего законодательства по ОИБ (обеспечению информационной безопасности) с применением ЭП для исполнения: целостности, доступности, конфиденциальности, в частности проводится анализ коммерческого сектора по рынку продуктов СЭД в защищенном исполнении, согласно ГОСТ Р 56939, в том числе в условиях импортозамещения. Рассматривается практический этап применения ЭП в судебно-исполнительной практике РФ в начальном формировании СЭД. Данные аспекты рассматриваются с упором на ключевые инциденты по судебно-исполнительной части в формате первичного применения ЭП, при этом не рассматривается eIDAS и соответствующим им форматам по работе с ЭП. Рассматривается формат приведения принципов и методов межведомственного электронного потокового документооборота. Также приводится политика движения рынка по СЭД в коммерческом секторе на сегодняшний день.

Введение

На базе прослеживаемой тенденции последних нескольких лет, согласно базы ежегодных отчетов от TadViser, в области автоматизации СЭД по рынку РФ, сформировался обобщенный рост интереса государства, в том числе коммерческого сектора к автоматизации потокового документооборота внутри и вне организаций для оптимизации основных и второстепенных БП (бизнес-процессов). Данная автоматизация осуществляется посредством СЭД, в том числе на уровнях межведомственных структур, как в коммерции, так и в бюджетных организациях. Стоит отметить, что под данную категорию попадет КИИ, вокруг которой до сих пор ходят споры в плане ОИБ, согласно ПП РФ 127 (для детализации понимания следует обратиться к приказам ФСТЭК России 227, 235, 239 и ФЗ РФ 187) который в данной статье не будет рассматриваться, так как эту серию планирую представить для изучения и разбора в следующих статьях с приведенной спецификацией по ним.

Действующая законодательная часть РФ по ЭП

Следует отметить, что для интеграции и соответствующей автоматизации СЭД внутри и вне организации следует выполнять определенный список-перечень требований, для корректного формирования работы и соблюдения действующего ГК, УК РФ, в частности из-за формирования законодательной базы КИИ.

Рассмотрим нормативно-правовую базу по автоматизации СЭД, относительно ИС, которая закрепляется в следующей законодательной документации, такой как:

1. Постановление Правительства РФ от 8 сентября 2010 года под 697 "О единой системе межведомственного электронного взаимодействия" с правками на 4 сентября 2020 года;
2. Федеральный закон Об электронной подписи 63 ФЗ от 06 апреля 2011 года, а именно: под Ст.2.п.1 Электронная подпись информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию, также Ст.4.п.3 Недопустимость признания электронной подписи и (или) подписанного ею электронного документа не имеющими юридической силы только на основании того, что такая электронная подпись создана не собственноручно, а с использованием средств электронной подписи для автоматического создания и (или) автоматической проверки электронных подписей в информационной системе;
3. Федеральный закон Об информации, информационных технологиях и защите информации 149 ФЗ от 27 июля 2006 года, а именно: под п. 4, 11 В целях заключения гражданско-правовых договоров или оформления иных правоотношений, в которых участвуют лица, обменивающиеся электронными сообщениями, обмен электронными сообщениями, каждое из которых подписано электронной подписью или иным аналогом собственноручной подписи отправителя такого сообщения, в порядке, установленном федеральными законами, иными нормативными правовыми актами или соглашением сторон, рассматривается как обмен документами;
4. Гражданский кодекс РФ (часть первая), а именно: под ст. 160 п. 2 Использование при совершении сделок электронно-цифровой подписи либо иного аналога собственноручной подписи допускается в случаях и в порядке, предусмотренных законом, также ст. 434 п. 2 Договор в письменной форме может быть заключен путем составления одного документа, подписанного сторонами, а также путем обмена документами посредством почтовой, телеграфной, телетайпной, телефонной, электронной или иной связи, позволяющей достоверно установить, что документ исходит от стороны по договору;
5. Федеральный закон О бухгалтерском учете 402 ФЗ от 6 декабря 2011 года;
6. Налоговый кодекс РФ (часть вторая) в редакции Федерального закона 229 ФЗ от 27 июля 2010, а именно: под ст. 169 п. 1 Счет-фактура может быть составлен и выставлен на бумажном носителе и (или) в электронном виде, также ст. 169 п. 6 Счет-фактура, составленный в электронном виде, подписывается электронной цифровой подписью руководителя организации либо иных лиц, уполномоченных на это приказом;
7. Арбитражный процессуальный кодекс РФ, а именно: под ст. 75 п. 3 Документы, полученные посредством факсимильной, электронной или иной связи, в том числе с использованием информационно-телекоммуникационной сети Интернет, также документы, подписанные электронной подписью или иным аналогом собственноручной подписи, допускаются в качестве письменных доказательств в случаях и в порядке, которые установлены настоящим Кодексом, другими федеральными законами, иными нормативными правовыми актами или договором либо определены в пределах своих полномочий Высшим Арбитражным Судом Российской Федерации;
8. Гражданский процессуальный кодекс РФ, а именно: под ст. 71 п. 1 Письменными доказательствами являются содержащие сведения об обстоятельствах, имеющих значение для рассмотрения и разрешения дела, акты, договоры, справки, деловая корреспонденция, иные документы и материалы, выполненные в форме цифровой, графической записи, в том числе полученные посредством факсимильной, электронной или другой связи либо иным позволяющим установить достоверность документа способом;
9. Законодательная часть по КИИ РФ, которая была приведена во Введении.

Практический опыт судебных дел по применимости ЭП в первичном применении

Рассмотрим несколько публичных примеров, которые сыграли важную роль на формирование ЭП, в плане ношения юридической силы и приемлемости на территории РФ:

1. Постановление Федерального арбитражного суда Волго-Вятского округа от 11 августа 2010 года по делу под N В3-5226/2010: ФАС Волго-вятского округа признал юридическую силу ЭЦП (так как ранее было применимо данное наименование ЭП), где истец требовал взыскания задолженности с ответчика за неоплаченный факсимильный товар, так как ответчик не признавал электронные документы, подписанные ЭЦП и утверждал, что данные документы подписаны неуполномоченным лицом, без какого-либо удостоверяющего центра с классом (речь идет о классах типа: квалифицированная подпись). По факту данного дела суд установил, что документы составлены в соответствии с формализованными требованиями, следовательно, между обеими сторонами было заключено дополнительное соглашение к первородному договору, в котором предусмотрено применение СЭД с использованием ЭЦП при составлении первичной документации, так как был представлен сертификат ЭЦП удостоверяющего центра (в отличии от нынешней механики взаимодействия), следовательно, суд постановил, что документы были подписаны уполномоченным лицом ответчика надлежащим образом;
2. Постановление Федерального арбитражного суда северо-западного округа от 1 июня 2009 по делу Г6-28501/2008: приведенный довод ИФНС об отсутствии у ОАО оснований для предъявления к вычету НДС по счету-фактуре, подписанному штампом-факсимилом воспроизводящим личную подпись руководителя организации-поставщика, что представленная подпись является не обоснованной, поскольку действующее законодательство РФ, в тот момент времени, не устанавливает допустимые форматы способов подписания счетов-фактур, в том числе не предусматривает запрет на подпись руководителя проставлением факсимильной подписи, которая представляется способом выполнения оригинальной личной подписи руководителя, что является альтернативой решения в плане применимости ЭП на тот момент времени;
3. Определение Высшего арбитражного суда Российской федерации от 13 февраля 2009 года под ВАС-16068/08: передача дела по заявлению о признании незаконными актами налогового органа по начислению налогов, начислению пеней, привлечении к налоговой ответственности по п. 1 ст. 122 НК РФ для пересмотра надзора судебных актов, где было отказано, поскольку представленные доказательства подтверждают наличия хозяйственных операций между заявителями и ООО. Отметим, что проставления на счетах-фактурах факсимильной подписи при наличии соглашения, не является нарушением обществом ст. 169 НК РФ, так же как альтернативное решение вышеописанных двух пунктов.

Следует сделать промежуточный вывод, что законодательство РФ по поводу электронного документооборота с применением ЭП, расширяет возможности переходов на безбумажные носители из года в год, перенимая наружную практику на базе КСЗИ, в зависимости от соблюдения локальных и федеральных ПП, НПА и ФЗ РФ о принятии решений в развитий данной семантики документооборота в цифровом варианте. Также первоочередные функций для СЭД были установлены нормами внутреннего потокового документооборота по БП. Данные нормы применялись в формате обмена данных, посредством электронных сообщений через почтовые ресурсы, взаимодействующих организаций которые далее подверглись стандартизации на базе архивных дел бумажных носителей. Вследствие течения нескольких лет по положениям законодательства РФ имело место тенденции унификации СЭД в государственных и муниципальных учреждениях, что в свою очередь позволило коммерческим организациям войти на рынок, в плане импортозамещения по запрашиваемым форматам автоматизации БП, где данный формат обязывает действовать подрядчиков по действующему законодательству РФ на организацию обеспечения ЗИ, ИБ так как данная документация подвергалась значительным утечкам, что в свою очередь не было достаточным для ОИБ по НСД.

Принципы и методы по ДОУ на базе СЭД с применением ЭП

Приведем спецификацию по утвержденным постановлениям и законодательным актам основополагающих принципов и методов межведомственного электронного потокового документооборота по ключевым БП, которые включают:

1. Предоставление обеспечения технологической возможности электронного документооборота определенным числом его участников;
2. Электронное сообщение, подписанное ЭП или иным аналогом собственноручной подписи, является электронным документом, равнозначным документу, подписанному собственноручной подписью, также устанавливается, что обмен электронными сообщениями, каждое из которых подписано ЭП или иным аналогом собственноручной подписи отправителя такого сообщения, в порядке, установленном ФЗ, иными НПА или соглашением сторон, рассматривается как обмен документами являющимся форматом СЭД;
3. Устанавливание требований и регламентационной базы в порядке расположения квалифицированного сертификата ЭП;
4. Устанавливание процедур взаимодействия участников электронного документооборота, в рамках выставления и получения счетов-фактур в электронном виде по информационно-телекоммуникационным каналам связи с применением ЭЦП, покрывающим ТЗКИ;
5. Документация в электронной форме, создается организациями, то есть участниками информационного взаимодействия в СЭД, в соответствии с требованиями законодательства РФ, а также внутренних НПА, устанавливающих правила (порядок) документирования, документооборота и использования документов;
6. Порядок документирования и организации работы с документами в формате ПИБО, устанавливается Инструкциями определенного рода, приказами руководителя организации, где Инструкция по делопроизводству детально регламентируют все делопроизводственные процессы применительно к документации в электронной форме, включающие методики по АСУ ТП;
7. Документы являются основой гражданских правоотношений и содержат основополагающие понятия, такие как сделка и договор;
8. Согласно п. 2 ст. 26.7 содержащая положения о том, что документы могут содержать сведения, зафиксированные как в письменной, так и в иной форме, к такой формации документов отнесены материалы фотосьемки и киносъемки, звукозаписи и видеозаписи, информационных баз данных, а также систем управления ими и иные носители информации в формате СКСН;
9. Установление состава реквизитов документации, требований к оформлению реквизитов документов, требований к бланкам документов, в том числе электронным;
10. Стандартизация регулирования процессов управления документацией, предназначенной для внутреннего или внешнего пользования посредством СЭД;
11. Положения специализированного стандарта, которые являются рекомендациями в создании систем управления документами в автоматизированном исполнении, обеспечения соответствия документов установленным характеристикам: аутентичность, достоверность, конфиденциальность, целостность, пригодность для использования и тому подобное;
12. Установление требований к составу и содержанию реквизитов, придающих юридическую силу документам на машинном носителе и машинограмме;
13. Содержание положений, позволяющих рассматривать электронные документы в качестве вещественных доказательств, при обязательном условии удостоверения документов при наличии ЭП, согласно УЦ;
14. Отраслевые кодексы, содержащие положения с электронными документами в соответствующих сферах деятельности;
15. Налоговый кодекс РФ в ст. 80, который содержит разрешение представлять налоговую отчетность в электронном виде;
16. Таможенный кодекс РФ в п. 8 ст.63, который закрепляет, что документация, необходимая для таможенного оформления может быть представлена в электронной форме;
17. Трудовой кодекс РФ в главе 49.1, в которой предусмотрено взаимодействие дистанционного работника или ответственного лица, поступающего на дистанционную работу, а также работодателя путем обмена документами на базе СЭД, в которых используются усиленные квалифицированные ЭП дистанционного работника, где в примечании указываются изменения по ТК РФ, которые были внесены введением в силу ФЗ РФ 60 от 05 апреля 2013 г. О внесении изменений в отдельные законодательные акты Российской Федерации;
18. Использование СЭД выявляет необходимость в ОИБ КДОУ (конфиденциального документационного обеспечения управления) и защиты обрабатываемой, и хранящейся информации, за исключением ФЗ РФ 149 и доктрины информационной безопасности, где в следствии которых следует употреблять положения ФЗ РФ 5485 О государственной тайне от 21 июля 1993 года и ФЗ РФ О коммерческой тайне от 29 июля 2011 года под 98 с определенным форматом ДСП для градации информации на С, СС, ОВ, либо конфиденциальной информации ОД, а также служебной, профессиональной тайне и иное. В этом случае если в деятельности организации создается информация, составляющая данные виды тайн, а также имеющие к ним отношения в соответствии с приказами от ФСТЭК России 17 от 11 Февраля 2013 г. и приказа ФСТЭК России 21 От 18 Февраля 2013 г. со всеми вытекающими форматами по ОИБ смежных и совокупных данных обрабатываемых СЭД;
19. Нормативные документы, предназначенные для определения сроков хранения, отбора на хранение и уничтожения типовых управленческих документов;
20. Нормы времени на работы по документационному обеспечению управленческих структур федеральных органов исполнительной власти, утвержденные Постановлением Минтруда 23 от 6 марта 2002 г.;
21. Уполномоченные лица межведомственных структур организации в применяемой СЭД с совместимыми технологиями ИС, ПО, в том числе форматов, протоколов информационного взаимодействия и унифицированных программно-технических средств;
22. Применение СПО и сертифицированных программно-технических средств на базе БДУ ФСТЭК России и классификации по модели атаки, и нарушителям, обладающих лицензиями от ФСТЭК России и ФСБ России, применяемого для участников межведомственного электронного документооборота в соответствии с действующим законодательством РФ;
23. Обеспечение основополагающих принципов ИБ, на базовом уровне, таком как: целостность, доступности и конфиденциальности передаваемой информации опосредованно внутри и вне СЭД;
24. Минимизация издержек, рисков по СУИБ, согласно семейства ISO/IEK 27000, включая KPI, в том числе финансовых и временных издержек, при осуществлении информационного взаимодействия между участников и уполномоченных лиц, также межведомственного электронного документооборота посредством СЭД в целях ОИБ организации;
25. Обеспечение конфиденциальности передачи и получения информации, посредством ТЗКИ, обладающих сертификатами соответствия от ФСТЭК России и ФСБ России, внутри, а также вне СЭД для ОИБ по действующему законодательству РФ.

Сделаем промежуточный вывод, где вследствие указанных принципов и методов применяемых в формирования СЭД, посредством автоматизации, прослеживается семантика для централизации и адаптации БП, согласно потокового документооборота. Вследствие чего был сформирован комплекс стандартов, где основным является ГОСТ Р 53898 от 2010 года Системы электронного документооборота. Взаимодействие систем управления документами. Требования к электронному сообщению на которые опирается автоматизация СЭД по основным и второстепенным БП, а также устанавливают политики состава и содержания электронного сообщения, с применением ЭП, которые обеспечивают информационное взаимодействие между систем управления, согласно ГОСТ и ОСТ РФ.

Движение рынка СЭД с изменением законодательства РФ

Рассмотрим формат движения рынка ЭДС с динамикой последних 5 лет, основываясь на статистике TadViser, включая законодательство РФ:

1. ПП РФ 1 от 1 января 2016 года, который заключил положения в плане запретительных политик на закупку зарубежного ПО для государственных и муниципальных нужд в ситуациях, когда имеется на отечественном рынке аналоги, не уступающие по качеству и функционалу с соответствующими, опираясь на сертификаты соответствия с ФСТЭК России. Как пример: ФЗ РФ 44;
2. СЭД интегрируются с BPM (Business Process Management) решениями, по программному обеспечению для автоматизации бизнес-процессов, также с сервисами интеллектуального поиска, бизнес-аналитики и коллективной работы сотрудников, в том числе для СУИБ на стандартах РФ, включая ИСО/МЭК;
3. Для предпринимателей, коммерческой структуры РФ по IT, представились преимущества облачных решений, как модель обеспечения сетевого доступа посредством сети, которые используются с минимальными эксплуатационными затратами или обращениями к провайдеру, по следующим причинам:
   3.1. Автоматизация СЭД по облачным решениям позволяет планировать финансовые затраты в формате минимизации на потреблении дополнительного серверного оборудования в формате DevOps;
   3.2. Перевод организационно-корпоративных данных в частное или публичное облако позволяет расширить параметры ИС организации и реорганизовать удалённый доступ для авторизованных пользователей (стоит отметить, что все зависит от типа информации для обеспечения ДОУ/КДОУ), разграничив согласно ФЗ и НПА, ПП РФ, что дает сотрудникам структурных подразделений организации возможность совместной работы над едиными управленческими и документационными задачами в режиме онлайн;
4. Наблюдается увеличение числа пользователей мобильных приложений ЭДС и самих исполнителей данных задач автоматизации и потокового обмена данных, в том числе по формату аутсорсинга, так как мобильные приложения дают возможность наблюдения за изменениями информации и контроля деятельности. Так за период 2015 года свыше 300 000 пользователей установили себе мобильное приложение 1С: Документооборот;
5. Лица могут воспользоваться персональной ЭП для формирования договоров или отчетной документации для заверения и обособленности информации.

Выводы

Частичная или полная автоматизация СЭД является целевым и первоочередным форматом развития организаций в настоящее время, с перспективами дальнейшего роста, как в бюджетных, так и коммерческих образованиях. Автоматизация СЭД в государственных и муниципальных учреждениях РФ ставится с целью ликвидного повышения эффективности, оптимизации, адаптивности, работоспособности органов структурных подразделений, где несмотря на тотальный контроль со стороны нормативных, организационных, управленческих, методических норм прослеживается формат развития законодательной части и государственного строя, как пример: законодательная часть в области КИИ.

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

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

P.S.: если ставите минус, прокомментируйте, пожалуйста, дабы в будущем мне не допускать подобных ошибок.

Аннотация

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

Исследование рассматривается со стороны коммерческого сектора и самых эффективных форматов безопасной разработки. Исследование рассматривается с применением в практической части данных вариатив и их специфик в целом, и частном формате. Целью данной статьи является передача опыта и аналитика данных применяемых методологий, методов и средств разработки в защищенном исполнении. В статье представлен анализ, соответствующий разбор действующего рынка, законодательства, в части касающейся разработки информационных систем и сред в защищенном исполнении, которая именуются также как безопасная разработка, и которая с каждым днем набирает "критическую массу" популярности в различных отраслевых компаниях из-за ужесточения рекомендаций и требований регуляторов ИБ [1].

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

Введение

Данная статья базируется на принципах и процессах автоматизации ИС и сред организации, где рассматривается вопрос со стороны личной практики как руководителя, так и разработчика. В статье представлено практическое оценочное мнение и его эффективность. Частично статья касается вопроса со стороны OWASP TOP 10, но акцент на этом будет поставлен в последующих статьях. Стоит отметить, что не рассматривается практика сертификации, аттестации, выполнении требований опытных лабораторий, проектирования ПО по ПП РФ 608, включая приказ ФСТЭК России 55 и иных документов по безопасной разработке в данном направлении. Рассматривается формат представления универсальных характеристик разработки в безопасном исполнении, автоматизации, оптимизации, масштабируемости, адаптации БП (бизнес процесс), в формате ГОСТ Р 56939.

В коммерческом секторе РФ отсутствует установленное понятие для всех ветвей организации управления организации, в сфере прямо или косвенно касающихся IT и смежных с данными подразделений, такого как: ИС (информационная система) и среда. В том числе отсутствует понимание ее классификации в целом и частном порядке. В общепринятом представлении на рынке в потребительской сфере также отсутствует понимание построения структуры и непосредственно семантики работы ИС и сред. Данный общепринятый формат объясняется следующим образом, что методы, средства и методологии разработки по созданию, оптимизации, масштабируемости, итерационной интеграции, введению в промышленную эксплуатацию каноничны, во всем промежутке времени, которые парраллелелись по различным специфичным и обособленным между собою направлениям с применением разного рода подходов и методов для их реализаций. В последствии чего стали возникать угрозы, риски и последствия инцидентов для организаций, которые занимались обработкой, хранением информации, в том числе остро возник вопрос по ОИБ (обеспечение ИБ) информации: целостности, доступности, конфиденциальности. Этот вопрос также будет разобран отдельно в следующих статьях, где стоит отметить, что важнейшим аспектом стало на сегодня ОИБ КИИ РФ, также отдельно взяло направление по оценке рисков и инцидентов, в формате СУИБ (система управления информационной безопасности) и многое другое. В последствии данных форматов и форм-факторов возник вопрос безопасной разработки в организациях, где направление стало развиваться в геометрической прогрессии и набирать экспоненциальные обороты.

Информация и ИС в безопасной разработке

Приведем ИС в автоматизированном исполнении по типам, которые имеются на сегодняшний день и в связи с которыми разрослись методы, средства и методологии их реализации в разработке, проектировании и прототипировании, а именно:

1. Автоматизированные системы управления:
   1.1. Техническими процессами;
   1.2. Предприятием;
   1.3. Производством.
2. Системы автоматизированного проектирования и расчета, проектирования технологических процессов;
3. Автоматизированные системы научных исследований;
4. Автоматизированные системы обработки, передачи данных и БД, такие как:
   4.1. Автоматизированные информационно-поисковые системы;
   4.2. Автоматизированные системы информационно-терминологического обслуживания.
5. Автоматизированные информационные системы, представляющие из себя агрегаторы информации;
6. Автоматизированные системы технологической подготовки производства;
7. Автоматизированные системы контроля и испытаний;
8. Автоматизированные комплексные системы, методологические функциональные возможности специфик предприятий;
9. Автоматизированные информационные системы общего назначения;
10. Автоматизированные системы научно-технологической формации, оптимизации и сведения;
11. Автоматизированные системы нормативно-правовой документации, нормативно-методического и методологического обеспечения управления предприятием;
12. Автоматизированные обучающие системы организации;
13. Автоматизированные системы виртуальной реальности;
14. Автоматизированные профессионально ориентированные системы, экономические информационные системы, такие как:
    14.1. Бухгалтерские;
    14.2. Банковские;
    14.3. Рынка ценных бумаг;
    14.4. Маркетинговые;
    14.5. Продажные.
15. Автоматизированные информационные системы профильного назначения по БП организаций.

Исходя из приведенного формата стоит дать определение термина информация, применяемого в безопасной разработке, касательно АИС (автоматизированная информационная система) в отношении действующего законодательства РФ, а именно:

1. Это совокупность сведений, не зависимо от их формы, которые представляют из себя формализованный или не формализованный вид сообщения в независимой и ликвидной, либо не ликвидной форме;
2. Это система комбинирования взаимодействующих элементов, организованных и структурированных форматов для достижения определенных поставленных целей и задач [2-5].

Следовательно, информация обрабатывается, передается и хранится, следовательно она подвержена определенным рискам со стороны злоумышленников и требуется обеспечение ее безопасности. Определим термин безопасность информации, который будем понимать как состояние уровня ее защищенности, которое обеспечивается сохранением качественных и количественных характеристик, а именно целостности, доступности, конфиденциальности. Если рассматривать со стороны IT-сферы, то ИС обеспечивает: сбор, хранение, обработку, поиск, оптимизацию, масштабируемость, адаптацию, то есть представление этой самой информации, которая применяется во время принятия управленческих решений любого рода в организации.

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

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

Далее отметим универсальные характеристики для безопасной разработки ИС, такие как:

1. Основное назначения функционирования: сбор, хранение и обработка информации;
2. Нацеленность функционирования АИС под потребительские нужны и цели, при необходимости реализации: объединения и распараллеливания функциональных возможностей АИС на подразделения и структуры, непосредственно самой организации;
3. Представление проектирования интерфейса, в том числе соотношения UI/UX, прикладного программно-аппаратного обеспечения, как принцип минимальной содержательной достаточности для представление реализации взаимодействия функционирования АИС с исключением эксплуатационной возможности НДВ (не декларированных возможностей), в целом и частном.

Общая спецификация методологий по безопасной разработки ПО

Под спецификацией методологии понимается объединение перечня средств и методов, применяющихся в специфике деятельности организации, со стороны теории и практики разработки, включая прототипирование. Методологией является формат объединения методов, средств и технологий, применяющихся во время всего жизненного цикла процесса разработки и прототипирования ПО в организации. Данный формат является совокупностью практически выработанного и действующего формата в узконаправленной специфике организации для всей программно-аппаратной части и комплекса в целом. Следовательно стоит отметить, что также под методологией безопасной разработки ИС понимается организация процессов прототипирования и выстраивания ИС и сред, таких как: обеспечения управления процессами для гарантированного выполнения ТТ, ТЗ и реорганизации процессов [6-10].

Приведем список-перечень задач для достижения обеспечения действенности методологии безопасной разработки ИС и среды, состоящей из:

1. Представления разработки и внедрения в промышленную эксплуатацию АИС, отвечающей целевым нуждам и спецификации по политикам работы организаций, в том числе ТТ и законодательных актов РФ, а также внутренних политик организаций и предъявленных к ним требований;
2. Предоставления гарантий выполнения требований действующих регуляторов из специфики организации и приложений на разработку и интеграцию АИС с заданными параметрами, относительно ТТ и ТЗ в течение утвержденного календарного плана, а также оговоренного бюджета на разработку. Данный формат также может рассматриваться исходя из применяемых методов разработки ПО;
3. Представления сопровождения технической и методологической части обучения, также модификации и масштабирования системы для обеспечения соответствия целевых нужд организаций, в том числе формата поддержания S.M.A.R.T.;
4. Представления обеспечения разработки и внедрения в промышленную эксплуатацию АИС, отвечающей требованиям оптимизированности, переносимости, масштабируемости, адаптивности;
5. Представления возможности вариативного использования в АИС разработанных средств и методов в программно-аппаратном обеспечении, СУБД, СУИБ и тому подобное. Отметим, что данный формат зависит от политик применяемых организацией, а также ее сферы деятельности.

Целью методологии является присвоение рамок конечного функционирования и бесперебойной работоспособности АИС по целевым и первоочередным нуждам организации. В реализации АИС применяются специализированные подсистемы ИБ для формирования средств и методов разработки и прототипирования посредством политик ИБ организации в СУИБ. Данные политики представляются в виде списка-перечня определенных действий для персонала, согласно определенной технологической базы и функционирования данных систем в настоящем, и будущем времени при использовании в промышленной эксплуатации.

Опираясь на сводную классификацию проектной части работы Одинцова И.О.: "Профессиональное программирование. Системный подход", следует выделить:

1. Классификацию по ядрам методологий, в которой утверждается, что имеет место быть ядру методологии с методами, которые уточняются дополнительными особенностями, а сами ядра определяются способами описания их алгоритмов, где к ним соотносятся:
   1.1. Методология императивного программирования, которая характеризуется принципом последовательного изменения состояния операнд итерационным образом, ориентированная на классическую модель Джона фон Неймана, получившей широкое практическое и теоретическое применение, с такими концепциями как:
   1.1.1. Метод последовательного изменения состояний, поддерживаемый концепцией алгоритма;
   1.1.2. Метод потокового управления на исполнение, в итерационном контроле.
   1.2. Методология объектно-ориентированного программирования (ООП), которая использует объектные декомпозиции. Отметим, что статическая структура ИС и сред описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами, как в UI/UX и системном программировании. Пример: инкапсуляция, то есть абстрактный тип данных, его наследование и полиморфизм, с применение таких методов как:
   1.2.1. Метод объектно-ориентированной декомпозиции, который заключается в выделении объектов и связей между ними, поддерживающийся концепциями инкапсуляции, наследования и полиморфизма;
   1.2.2. Метод абстрактных типов данных, который лежит в основе инкапсуляции, поддерживающийся концепцией абстрагирования;
   1.2.3. Метод пересылки сообщений, который заключается в описании поведения системы в терминах обмена сообщениями между объектами, поддерживаемый концепцией сообщения.
   1.3. Методология функционального программирования как способ составления программно-аппаратной части, в которой единственным действием является вызов функции, как вариативы, то есть способа расчленения программно-аппаратной части на отдельные сектора, где имеет место быть формат введения имени для функции и задания для него вычисляющего значения, применяемый с такими методами концепций как:
   1.3.1. Метод аппликативности, где: программно-аппаратная часть есть выражение, которое подставлено из функции к аргументу, состоящему из определения функции, представляющей собой вызов от другой функций и вложенной друг в друга, поддерживается концепцией функции;
   1.3.2. Метод рекурсивного поведения, который заключается в самоповторяющемся поведении, то есть возвращающемуся к самому себе, поддерживается концепцией рекурсии;
   1.3.3. Метод настраиваемости, который заключается в порождении новых программных объектов по специальному образцу, где значения соответствующих выражений применяется как порождающая функция к параметрам образца [11].
   1.4. Методология логического программирования, где программно-аппаратная часть содержит описание проблемы в терминах фактов и логических формул, а решение проблемы ИС и среды выполняется с помощью механизмов логического вывода, где применяются такие методы и концепции как:
   1.4.1. Метод единообразия, где используется применение механизма логического доказательства ко всей программе;
   1.4.2. Метод унификации, то есть механизм сопоставления с образцом для создания и декомпозиции структур БД.
   1.5. Методология программирования с ограничениями, при котором в ПО определяется тип данных для его решения, где предметная область шифруется на соответствующие ограничения значений искомого решения, которая находится в ИС и средах. В данной методологии предлагается двухуровневая архитектура, которая интегрируется как компонент ограничения программно-аппаратного компонента. В данном формате подразумевается описательная модель вычислений, где программа содержит описание понятий и задач в формате поддерживания концепции модели.
2. Классификацию по топологической специфике самой методологий то есть форм-факторы топологии на базе методологии со способностью выбора самих методов для получения уточненного ядра, с такими методами и концепциями как:
   2.1. Последовательная декомпозиция алгоритма решения задачи сверху вниз в итерационной детализации, которая начинается с общей задачи и обеспечивает ее структурированность, которая поддерживается концепцией алгоритма;
   2.2. Метод модульной организации частей программы, где происходит разбиение программы на специальные компоненты, которые поддерживаются концепцией модуля;
   2.3. Использование структурного кодирования, где используется кодирование трех основных управляющих конструкций, которые поддерживаются концепцией управления.
3. Классификацию по реализационной специфике методологии, где применяется использование каждого из ядер методологии с конкретной спецификой. В данной классификации определяется некоторая организация аппаратной поддержки, такая как: централизованная или параллельная, использующаяся для централизованных архитектур;
4. Классификацию по смешанной методологии, которая включает объединение методов нескольких методологий, таких как методологии функционального и логического программирования;
5. Классификацию по идейной задумке Петрова В.Н.: "Технологии разработки программного обеспечения", являющейся методологией RAD (Rapid Application Development). Данная методология носит наименование методологии быстрой разработки приложений. Целевая предпосылка в области инструментальных средств быстрой разработки приложений основана на таких элементах как:
   5.1. Объёмное положение разработчиков, которые разрабатывают АИС со всей спецификой и вариацией относительно ТТ, ТЗ. Например: минимальная группа разработчиков, представляет из себя от 2 до 10 человек, для большей части вариатива, может достигать до 100 разработчиков, такая специфика прослеживается в основном в игровой индустрии;
   5.2. Тщательная проработка производственного графа работ кадрового состава организации, его оптимизации и управления над ним, так же влияющий на календарный план разработки и прототипирования. Данный граф по временным отрезкам представляется от 2 до 6 месяцев, в среднем, но все зависит от целевых нужд организации для АИС, согласно ТТ и ТЗ.

Следует отметить, что приведенные методологии позволяют обеспечить безопасную разработку в организации по всем БП, что в свою очередь облегчит функционирование организации и управления кадровым составом, а это позволить повысить рентабельность и ликвидность конечного продукта. Данные форматы являются опосредованными и целостным, где позволят предотвратить методы и меры по OWASP TOP 10, что снизит риски и шансы возникновения инцидентов, а также их расследований по семейству ISO/IEK 27000.

Принципы выбора методологий в безопасной разработке

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

Следовательно, первоочередно стоит привести классическую (каноническую, монументальную) методологию, которая применяется исходя из наличия следующих принципов, таких как:

1. Четкое понимание необходимого и конечного функционала, дизайна, прототипа интерфейса UI/UX и всей грядущей разработки АИС, то есть присутствует детализация специфики АИС. Стоит отметить, что она является четко регламентированной, с конечным конкретным ТЗ и ТТ, где описано: что и как должно работать;
2. Формализованные целевые нужды конечного потребителя, тогда когда разработчики и руководящий состав, включая Заказчика представляют четкую "картину" в документированном виде, то есть: создается подробное ТЗ, где данная дефиниция регламентируется полноценным процессным состоянием каждого элемента в АИС, которая также содержит полноценное описание в цикле по специализированным алгоритмам, включая детализацию по UI/UX;
3. Конечные требования к АИС являются стабильными, вследствие чего потребитель не дополняет условий по изменению функциональности АИС во время ее разработки, модернизации, исключая возможный формат блочного масштабирования в рамках текущих отношений;
4. Представление итерационного процесса в формации аналитики, где проектирование и разработка ТЗ строго линейно.

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

Приведем далее более гибкую адаптивную методологию, которая применяется по следующим принципам, таким как:

1. Предоставляются не понятийные, изменчивые требования к АИС;
2. Потребителю предоставляется разрабатываемая АИС только в общих очерках, где предполагается внесение изменений функциональности или дизайна разрабатываемой АИС посредственно в сам момент произведения процесса разработки;
3. Представление необходимости быстрого получения первых вариаций версионности продукта и дальнейшего масштабирования исходя от нужд организации и решений Digital, в момент работающего АИС;
4. Представление решаемой задачи посредством программно-аппаратного комплекса АИС неэффективно поддается документированию по объективным причинам;
5. Представление реализации всех требований к проекту, вновь внесенных в том числе, которые варьируется как добавочный ликвидный запас временного отрезка для разработки и прототипирования.

Приведенная методология позволяет спрогнозировать разностороннюю вариативность при разработки и прототипировании продукта, исходя из общего формата различных пользовательских кейсов, в том числе со стороны злоумышленник по типу: "а как бы это сделал я?". Методология позволяет предопределить возможные вариативные изменения в процессе разработки и контролировать итерационность получаемого продукта, что позволяет "бизнесу" контролировать риски, в том числе со стороны финансирования организацией. Отмечу, что приведенные принципы схожи с возможностью изменения продукта исходя из метрик при анализе для "бизнеса", что позволяет в процессе разработки контролировать все жизненные циклы и процессы версионности продукта, в том числе монетизирования. Этот формат подходит для долгосрочных продуктов, которым необходимо иметь возможность постоянной монетизации и частично быть конкурентноспособными исходя из максимизации перекрытия спроса предложением [12].

Следует предоставить и разобрать самые признанные и распространённые манифесты для представления гибкой безопасной разработки ПО, таких видов как:

1. Manifest for Agile Software Development, который был разработан с целью альтернативного решения в плане использования канонической методологии для разработки ПО и поддержания максимизации выходных параметров для продукта из ресурсов организации;
2. SCRUM реализуемая посредством создания "резервирования свойств системы", под резервом свойств понимается набор функциональных систем, которые необходимы для реализации, а функции описываются с помощью пользовательских сценарных подходов. Отличительная черта данной методологии представляется как проведение ежедневных митингов и обсуждений, которые называются stand-up, где в ходе совещания задаются каждому разработчику вопросы, такого типа:
   2.1. Что удалось выполнить для решения той или иной итерации за день?
   2.2. Какие были проблемы в моменте реализации?
   2.3. Что и как планируется сделать за сегодняшний день?
   2.4. Как происходит интеграция и оптимизация ПО в данном интервале?
   2.5. Иные виды вопросов исходя из практики организации.
3. Экстремальное программирование: eXtreme Programming, XP, которое обладает простотой решения, интенсивной разработкой малыми группами состава разработчиков, спецификой активного общения, где также "бизнес" напрямую вовлечён в процесс разработки;
4. Семейство методологий Crystal разработанная Алистером Коберном, который рассматривал процесс разработки как конечную целенаправленную игру, где утверждается, что у этой игры есть следующие цели, такие как:
   4.1. Основная цель, которая заключается в успешном закачивании разработки проектной части и внедрении в промышленную эксплуатацию;
   4.2. Вспомогательная цель, которая представляется в подготовке к следующей игре, для которой необходима определенного рода документация для разработки в виде оптимизированного и адаптированного исходного кода. Данная вариатива облегчает последующее масштабирование, а также поддержку продукта и тому подобное.
5. Адаптивная методология, под наименованием: Adaptive Software Development, ASD это альтернатива традиционного ориентирования на процессы, посредством методов управления разработкой, где результат представляется как минимизация процессов при максимальном увеличении взаимодействий между людьми. Также данная методология базируется на принципах непрерывной адаптации, где постоянные вариативные изменения в проектной части становятся нормированной практикой. В данном случае жизненный процессный цикл: "Планирование Проектирование Конструирование" изменен на более адаптивный и динамичный, такой как: "Обдумывание Взаимодействие Обучение;
6. Функционально-ориентированная разработка, под наименованием: Feature Driven Development, FDD, где та или иная функция реализовывается за две недели, если даже сценарии использования являются достаточно малыми, которые включают пять основных процессов:
   6.1. Разработка общих моделей;
   6.2. Составление списков необходимых функций для ПО;
   6.3. Планирование исполнительных работ над функциями;
   6.4. Проектирование самих функции;
   6.5. Конструирование самих функции.

Отмечу, что данные манифесты являются применимыми, но не всегда корректно, так как имеется практика введения только положительных методов из них, а не полноценного формата контроля и управления, где руководящий состав организации считает, что это будет наиболее эффективно, нежели чем процесс полноценной интеграции конкреной системы, что приводит к не корректному взаимодействию внутри команды и процесса разработки дающего только отрицательный характер влияния на "бизнес". Для безопасной разработки ПО считаются важными данные аспекты методологии, управления, разработки и проектирования, так как они позволяют решить подавляющую часть проблем связанных с рисками и инцидентами ИБ, в том числе выполнить и перекрыть требования, и рекомендации регуляторов ИБ и обезопасить конечный продукт, а также "бизнес". В том числе учитываются специалисты по PenTest, DevSecOps и так далее, так как профильные специалисты с опытом смогу предоставить ОИБ организации [13-15].

Выводы

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

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

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

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

P.S.: если ставите минус, прокомментируйте, пожалуйста, дабы в будущем мне не допускать подобных ошибок.