Приказ 455 О создании автоматизированной системы Госреестра

Приказ Госстандарта РФ
от 27 октября 1999 г. № 455

«О создании автоматизированной системы Госреестра»

В настоящее время разработаны и утверждены Госстандартом России документы, обеспечивающие деятельность по ведению Государственного реестра (далее — Госреестр): «Положение о Государственном реестре» * , «Правила по сертификации. Временный порядок ведения в Государственном реестре объектов и участников Системы сертификации ГОСТ Р» ** , «Правила проведения государственной регистрации систем сертификации и знаков соответствия, действующих в Российской Федерации» *** (зарегистрированы в Минюсте России 14 июня 1999 г., регистрационный номер 1795.)

* Вестник Госстандарта России. — 1999. — № 6. — С.57.

** Вестник Госстандарта России. — 1999. — № 6. — С.59.

*** Вестник Госстандарта России. — 1999. — № 10. — С.63.

Завершены работы в Госреестре по подготовке помещения, размещению и упорядочению документации зарегистрированных объектов.

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

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

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

Перечисленные задачи требуют усиления технической базы Госреестра.

С целью дальнейшего совершенствования деятельности Госреестра приказываю:

1 . Управлению сертификации (М.Л. Рахманову), ВНИИС (В.Г. Версану), консультационно-внедренческой фирме «Интерстандарт» (С.И. Ерофееву) обеспечить с 5 ноября 1999 г. постоянную эксплуатацию автоматизированной системы Госреестра в составе основных реквизитов зарегистрированных объектов.

2 . В целях внедрения автоматизированной системы Госреестра в полном объеме и создания необходимых условий для ее функционирования:

Управлению сертификации (М.Л. Рахманову), консультационно-внедренческой фирме «Интерстандарт» (С.И. Ерофееву), ВНИИС (В.Г. Версану) в срок до 15 ноября 1999 г. создать в помещении Госреестра локальную вычислительную сеть на 4 рабочих места с выделенным сервером, соединенным с сервером Госстандарта России.

Управлению экономики (П.С. Пранову) обеспечить финансирование приобретения необходимых технических средств; консультационно-внедренческой фирме «Интерстандарт» (С.И. Ерофееву), ВНИИС (В.Г. Версану) завершить разработку и наполнение в расширенном составе реквизитов баз данных (далее — БД) зарегистрированных объектов Госреестра:

БД «Системы сертификации» — в ноябре 1999 г.

БД «Органы по сертификации» — в декабре 1999 г.

БД «Испытательные лаборатории» — в феврале 2000 г.;

Управлению сертификации (М.Л. Рахманову), Техническому центру Регистра систем качества (В.И. Плеханову), ВНИИС (В.Г. Версану), консультационно-внедренческой фирме «Интерстандарт» (С.И. Ерофееву) подготовить в декабре 1999 г. предложения по созданию и ведению баз данных: о системах сертификации, имеющих в области своей деятельности сертификацию систем качества, об отечественных и зарубежных организациях по сертификации систем качества, работающих на российском рынке, о предприятиях и организациях, сертифицировавших свои системы качества.

3 . Управлению сертификации (М.Л. Рахманову), ВНИИС (В.Г. Версану) разработать и в феврале 2000 г. представить на утверждение «Порядок информационного обслуживания данными Госреестра аппарата Госстандарта России, его территориальных органов, других органов и организаций».

4 . Управлению сертификации (М.Л. Рахманову), ВНИИС (В.Г. Версану), консультационно-внедренческой фирме «Интерстандарт» (С.И. Ерофееву) с целью обеспечения проведения анализа результатов сертификации на основе современной информационной технологии создать систему сбора и анализа копий выданных органами по сертификации сертификатов соответствия.

Утвердить прилагаемый план-график работ по созданию системы сбора и анализа копий сертификатов соответствия, представляемых органами по сертификации в электронном виде (база данных «Сертификаты»).

5 . Управлению экономики (П.С. Пранову) обеспечить частичное финансирование работ, выполняемых ВНИИС по совершенствованию и ведению Государственного реестра.

6 . Контроль за выполнением настоящего приказа оставляю за собой.

Председателя Госстандарта России И.А. Коровкин

План-график
работ по созданию системы сбора и анализа копий сертификатов соответствия, представляемых органами по сертификации в электронном виде (база данных «Сертификаты»)

www.gosthelp.ru

Приказ о разработке программного обеспечения




Пример П Р И К А З А

4 июня 2001 № 34 \ 231

О внедрении технологии организационного реинжиниринга в
ЗАО “ДО ПОСЛЕ ВСЕГО”

С целью оптимизации бизнес-процессов и повышения качества разрабатываемой в ЗАО “ДО ПОСЛЕ ВСЕГО” технологической документации, а также создания необходимых условий для аттестации компании по требованиям стандарта обеспечения качества услуг ГОСТ Р ИСО 9001-9003 приказываю:

1. Для контроля качества технологической (регламентационной) документации ЗАО “ДО ПОСЛЕ ВСЕГО” создать Комитет технического контроля и стандартизации бизнес процессов (далее — Комитет) в следующем составе:

Председатель комитета — Айдифов П.П.

Эксперты комитета — Руководители подразделений (или уполномоченные ими
сотрудники по согласованию с Председателем Комитета)

Секретарь комитета — Садтков П.П.

2. Планирование, организацию и координацию разработки бизнес-процессов, являющихся продуктом проектных работ, а также внесение изменений в технологические (регламентационные) документы осуществлять в соответствии c «Положением о разработке технологических документов в ЗАО “ДО ПОСЛЕ ВСЕГО”» (далее – Положение) (Приложение 1 ).

Ответственный за контроль исполнения – председатель Комитета.

3. Утвердить Модель бизнес-процессов (МБП Вер. 1.06.2001) (Приложение 2 ) в качестве базового требования (набора спецификаций) к бизнес-процессам подразделений ЗАО “ДО ПОСЛЕ ВСЕГО” . Обеспечить публикацию обновлений МБП в соответствии с Положением не позже 1 суток после внесения в нее изменений.

Ответственный за сопровождение модели – секретарь Комитета

4. С 1 июня 2001 г. вся разрабатываемая технологическая документация, а именно:

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

в обязательном порядке должна проходить аттестацию (рецензирование) в Комитете в соответствии с Положением. Аттестация предшествует всем иным видам согласования документов. Не прошедшая аттестацию техническая документация не подлежит исполнению.

Ответственный за контроль исполнения – председатель Комитета.

к Приказу № _ 34 \ 231 __ от _ 4 июня 2001 _2001 г.

Положение о разработке технологических документов
в ЗАО “ДО ПОСЛЕ ВСЕГО”

1. Базовые понятия.

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

Бизнес-процесс – операция (деятельность), включенная в систему операций, целью которой является производство и поставка услуг\товаров (1) операциям, входящим в систему, а также (2) другим системам. У каждого бизнес-процесса есть «владелец» — подразделение, группа исполнителей или один исполнитель.

Процессная модель организации (или бизнес-модель) — формализованное описание системы бизнес-процессов организации по правилам, принятым в организации, и оформляемая в виде документа для служебного пользования.

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

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

2. Общие положения

Для описания бизнес-процессов (формирования моделей бизнес-процессов) в ЗАО “ДО ПОСЛЕ ВСЕГО” используется единая для всех подразделений методология структурного анализа и проектирования SADT (URL: http://www.corp.ext.ru/sadt/SADT/SADT.htm ).

Инструментом разработки моделей бизнес-процессов является программный пакет BPwin.

Все технологические документы в ЗАО “ДО ПОСЛЕ ВСЕГО” разрабатываются на основании утвержденных Комитетом технического контроля и стандартизации бизнес-процессов (далее — Комитет) моделей бизнес-процессов. Они не должны противоречить моделям бизнес-процессов или содержать в себе новые (дополнительные) свойства.

К технологическим документам относятся:

· технологии проведения работ и предоставления услуг,

· процедурные правила взаимодействия подразделений,

· служебные инструкции, инструкции операторов,

· технические задания на разработку программных продуктов и услуг.

3. Порядок утверждения и корректировки моделей бизнес-процессов

Аттестация технологического документа (модели бизнес-процесса) предшествует всем иным видам согласования подобных документов. Не представленная для аттестации в Комитет и не прошедшая аттестацию техническая документация не подлежит исполнению.

Технологические документы представляются на аттестацию в Комитет в виде диаграмм, выполненных в соответствии со стандартом IDEF0 (URL: http://www.corp.ext.ru/sadt/SADT/chapter0102.html ).

Аттестация документов осуществляется Комитетом в соответствии с процедурой асинхронного рецензирования, определенной стандартом SADT (URL: http://www.corp.ext.ru/sadt/SADT/chapter0312.html ). Решение об окончании асинхронного рецензирования принимается Председателем Комитета самостоятельно или по предложению Секретаря Комитета. В случае положительного решения об аттестации модели бизнес-процесса Председатель Комитета визирует IDEF0 диаграммы бизнес-процесса.

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

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

4. Порядок корректировки Модели бизнес-процессов компании

Инициируется Председателем Комитета как по предложению Секретаря Комитета, в обязанность которого входит техническое сопровождение МБП в целом, так и самостоятельно.

Председатель Комитета несет личную ответственность за инициацию корректировки МБП в случае возникновения неустранимого конфликта в процессе аттестации бизнес-процесса.

Корректировка МБП заключается в разработке новых бизнес-процессов или корректировке бизнес-процессов, уже прошедших аттестацию. Эта процедура осуществляется в соответствии с общими правилами аттестации бизнес-процессов.

Публикация МБП и информации об изменениях в ней осуществляется на специализированном корпоративном www-сайте по адресу URL : http://www.corp.ext.ru/sadt .

5. Участие рецензентов в процедуре аттестации бизнес-процессов

В соответствии с методологией SADT к аттестации бизнес-процессов безусловно привлекаются рецензенты («читатели»). Рецензентами являются, руководитель подразделения, в состав которого входит автор модели бизнес-процесса, и другие руководители подразделений, бизнес-процессы которых являются поставщиками «услуг» аттестуемому процессу или потребителями «услуг» последнего.

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

На проведение каждой из итераций рецензирования 1 (одного) листа IDEF0-диаграммы отводится не более 1 рабочего дня. Количество необходимых итераций рецензирования определяет Председатель Комитета.

6. В случае проведения проектных работ на рецензирование может представляться несколько бизнес-процессов, объединяемых в частную модель. В этом случае ответственность за исполнение требований SADT при разработке такой частной модели до начала процедуры рецензирования несет руководитель проекта.

Разработка технических заданий (спецификаций, требований) на исполнение работ внутренними и внешними разработчиками (поставщиками) услуг и продуктов осуществляется в соответствии с правилами SADT – процедурой управления проектами (URL: http://www.corp.ext.ru/sadt/SADT/chapter0420.html ).

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

7. Порядок внутреннего учета

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

к Приказу № __ 34 \ 231 _ от _ 4 июня 2001 _ 2001 г.

Модель бизнес-процессов ЗАО “ДО ПОСЛЕ ВСЕГО”

1. Общие положения

Модель бизнес-процессов ЗАО «ДО ПОСЛЕ ВСЕГО» (далее – Модель) является развиваемым на постоянной основе внутренним продуктом коллективной деятельности подразделений, направленной на совершенствование бизнес процессов компании.

Модель представлена в виде электронного документа, хранящегося в файле с именем « SControl.bp1 » в электронной библиотеке бизнес-процессов компании и исполненного в формате, поддерживаемом инструментом проектирования организационных процессов Bpwin 2.5.

2. Размещение текущей версии Модели

or-rsv.narod.ru

Приказ о разработке программного обеспечения

Приказ «О разработке детального плана-графика реализации государственной программы Российской Федерации «Информационное общество (2011 – 2020 годы)» на 2014 год и плановый период 2015 и 2016 годов»

МИНИСТЕРСТВО СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ

О разработке детального плана-графика реализации государственной программы Российской Федерации «Информационное общество
(2011 – 2020 годы)» на 2014 год и плановый период 2015 и 2016 годов

В целях разработки детального плана-графика реализации государственной программы Российской Федерации «Информационное общество (2011 – 2020 годы)», утвержденной распоряжением Правительства Российской Федерации от 20 октября 2010 г. № 1815-р (Собрание законодательства Российской Федерации, 2010, № 46, ст. 6026; 2011, № 22, ст. 3173; № 51, ст. 7543; 2012, № 4, ст. 514; № 21, ст. 2662; № 35, ст. 4836; № 51, ст. 7269; № 52, ст. 7570; 2013, № 1, ст. 73; № 30, ст. 4115) (далее – Программа), а также в соответствии с Порядком разработки, реализации и оценки эффективности государственных программ Российской Федерации, утвержденным постановлением Правительства Российской Федерации от 2 августа 2010 г. № 588 (Собрание законодательства Российской Федерации, 2010, № 32, ст. 4329; 2012, № 22, ст. 2871; № 51, ст. 7218; № 53, ст. 7915), и методическими указаниями по разработке и реализации государственных программ Российской Федерации, утвержденными приказом Министерства экономического развития Российской Федерации от 26 декабря 2012 г. № 817 (Зарегистрирован в Министерстве юстиции Российской Федерации 6 февраля 2013 г., регистрационный № 26871),

1. Утвердить прилагаемый график (дорожную карту) подготовки детального плана-графика реализации Программы на 2014 год и плановый период 2015 и 2016 годов, согласно приложению № 1 к настоящему приказу.

2. Департаментам Министерства связи и массовых коммуникаций Российской Федерации (далее – Министерство), ответственным за реализацию мероприятий (далее – ответственные исполнители), обеспечить подготовку и предоставление в Департамент государственной политики в области информатизации органов власти (далее — ДГПИОВ) предложений для включения в проект детального плана-графика реализации Программы на 2014 год и плановый период 2015 и 2016 годов (далее – План) в сроки, согласно приложению № 1 к настоящему приказу по форме, согласно приложению № 2 к настоящему приказу, а также паспортов проектов по форме, согласно приложению № 3 к настоящему приказу.

3. Ответственным исполнителям обеспечить подготовку и предоставление в Департамент координации информатизации (далее — ДКИ) финансово-экономических обоснований мероприятий по информатизации (далее – ФЭО), предлагаемых для включения в План на 2014 год в сроки, согласно приложению № 1 к настоящему приказу, по форме, согласно приложению № 4 к настоящему приказу.

4. ДГПИОВ в суточный срок после завершения приема заявок от ответственных исполнителей направить в Правовой департамент (ПД) и Департамент экономики и финансов (ДЭФ) сводный перечень заявок для проведения экспертизы.

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

6. ДКИ обеспечить проведение экспертизы представленных ФЭО и направить заключение ответственному исполнителю, а также копию в ДГПИОВ в сроки, согласно приложению № 1 к настоящему приказу.

7. Определить, что в План могут быть включены проекты, удовлетворяющие следующим требованиям:


    наличие правовых оснований реализации проекта (согласованное с ПД);

возможность финансирования проекта (согласованная с ДЭФ)

соответствие целям и задачам Программы;

обоснование положительного влияния результатов проекта на показатели (индикаторы) Программы;

соответствие проекта основному мероприятию и мере в Программе;

  • наличие ФЭО (согласованного с ДКИ).
  • 8. ДГПИОВ в срок, согласно приложению № 1 к настоящему приказу, обеспечить подготовку сводного Плана.

    9. ДГПИОВ в срок, согласно приложению № 1 к настоящему приказу представить План на утверждение Министру связи и массовых коммуникаций Российской Федерации.

    10. Контроль за исполнением настоящего приказа оставляю за собой.

    Министр Н.А. Никифоров

    К приказу Министерства связи и массовых коммуникаций Российской Федерации
    от 29.10.2013 № 323

    К приказу Министерства связи и массовых коммуникаций Российской Федерации
    от 29.10.2013 № 323

    minsvyaz.ru

    Требования к безопасной разработке ПО согласно приказу ФСТЭК №31

    В приказе ФСТЭК №31 (далее — приказ №31) есть «особенная» подсистема мер, которой нет в аналогичных приказах ФСТЭК для ГИС и ИСПДн, а именно «обеспечение безопасной разработки ПО» (далее — ОБР).

    Что мы знаем об ОБР? Например, что в этом направлении ведется нормотворческая работа, примером тому служит проект ГОСТ Р «Обеспечение безопасной разработки ПО» (далее – проект ГОСТ). Посвящен он созданию системы управления безопасной разработкой ПО (далее — СУБР ПО) организацией-разработчиком ПО и учитывает, например, такие практики как Microsoft SDL, Cisco CDL, OWASP CLASP и положения ГОСТ Р ИСО/МЭК 15408-3, ГОСТ Р ИСО/МЭК 27001. Одной из причин создания данного ГОСТ является тот факт, что «виновниками»инцидентов ИБ чаще всего становятся дефекты безопасности и уязвимости программ. Актуальность защиты самого ПО (в том числе применяемого в промышленных системах автоматизации) от угроз, связанных с наличием в нем уязвимостей, не вызывает сомнения (Рисунок 1).

    Рисунок 1 – Распределение уязвимостей кода программных средств АСУ ТП и ПО программно-аппаратных средств АСУ ТП согласно сведениям банка данных угроз безопасности информации ФСТЭК

    Проект ГОСТ устанавливает требования к процессу разработки программного обеспечения и определяет следующие группы мер, направленные на обеспечение безопасной разработки ПО:

    • управление конфигурациями;
    • безопасная поставка ПО;
    • защита инфраструктуры разработки ПО;
    • защищенное программирование.

    Сравним положения проекта ГОСТ с мерами защиты информации подсистемы ОБР Приказа №31 (Таблица 1).

    Таблица 1 – Соответствие положений проекта ГОСТ и требований подсистемы ОБР Приказа №31.

    Меры защиты информации подсистемы ОБР Приказа №31

    Положения проекта ГОСТ (требования к организации-разработчику ПО)

    ОБР.0:Разработка правил и процедур (политик) обеспечения безопасной разработки программного обеспечения

    Определить и задокументировать политику обеспечения безопасности разработки ПО

    ОБР.1:Анализ уязвимостей и угроз безопасности информации в ходе разработки программного обеспечения

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

    ОБР.2:Статический анализ кода программного обеспечения в ходе разработки программного обеспечения

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

    ОБР.3:Ручной анализ кода программного обеспечения в ходе разработки программного обеспечения

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

    ОБР.4:Тестирование на проникновение в ходе разработки программного обеспечения

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

    ОБР.5:Динамический анализ кода программного обеспечения в ходе разработки программного обеспечения

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

    ОБР.6:Документирование процедур обеспечения безопасной разработки программного обеспечения разработчиком и представление их заказчику (оператору)

    Документация системы управления безопасной разработкой ПО должна включать в себя:

    -политику обеспечения безопасности разработки ПО;

    -описание области функционирования (логические и физические границы) системы управления безопасной разработкой ПО;

    -подход к оценке рисков, связанных с обеспечением безопасной разработки ПО;

    -документированные свидетельства реализации мер по обеспечению безопасности разработки ПО

    Отдельный пункт в проекте ГОСТ посвящен описанию необходимого комплекта документации и требований к управлению документацией СУБР ПО.

    Что касается моделирования угроз и выявления уязвимостей в проекте ГОСТ выделена необходимость:

    • собственно, моделирования угроз c целью выявления потенциальных дефектов безопасности и уязвимостей;
    • рассмотрения при идентификации рисков перечня актуальных угроз (приведен в проекте ГОСТ с указанием источника угроз, возможных последствий реализации угрозы, мер, направленных на парирование угроз);
    • анализа изменений перечня угроз безопасности, имеющих отношение к СУБР ПО, и установки требований к предупреждающим действиям;
    • проектирования архитектуры программы с учетом устранения потенциальных дефектов безопасности и уязвимостей разрабатываемой программы;
    • проведения динамического, статического анализа программы, инспекции исходных модулей программы, тестирования на проникновениес целью выявления дефектов безопасности и уязвимостей программы;
    • реализации процедуры, позволяющей выполнять отслеживание и исправление всех обнаруженных дефектов безопасности и уязвимостей программы.

    Все бы ничего, но, в силу особенностей процесса разработки прикладного ПО АСУ ТП и его специфичности, возникают вопросы к реализации некоторых требований, которые в условиях отсутствия соответствующих методических документов к Приказу №31, воспринимаются через призму субъективного мнения.

    Чтобы не заблудиться в своих рассуждениях, мы решили обратиться непосредственно к разработчику Приказа №31, и делимся с вами результатами (Таблица 2). К слову, спасибо представителям ФСТЭК, которые очень подробно ответили на все вопросы в течение месяца, и даже позвонили, чтобы пояснить ответы)).

    Таблица 2 – Комментарии ФСТЭК к подсистеме ОБР Приказа №31

    Вопрос, касающийся подсистемы ОБР Приказа №31

    Выдержка из ответа представителей ФСТЭК

    Являются ли инженеры-программисты (представители оператора АСУ), разрабатывающие/дорабатывающие прикладное программное обеспечение для функционирования АСУ ТП (мнемосхемы, алгоритмы ПЛК и т.д.) разработчиками согласно терминологии приказа №31

    К разработчикам системы защиты информации АСУ относятся в том числе инженеры-программисты, привлекаемые к разработке/доработке прикладного ПО для обеспечения безопасности информации в АСУ

    В случае самостоятельной разработки прикладного программного обеспечения операторами АСУ и необходимости выполнения ими требований к ОБР, какие из анализаторов кода можно использовать? Ведь на данный момент известные анализаторы кода (Safe ERP, Infowatch APPERCUT, SolarinCode, PVS-Studio и т.п.) не ориентированы на SCADA-пакеты и АСУ в целом (не поддерживают языки программирования ПЛК, к примеру)

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

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

    Может ли оператор АСУ использовать ПО стороннего разработчика, который не выполняет требования ОБР.0-ОБР.6 при разработке ПО? Если да, то при каких условиях?

    В соответствии с пунктом 13.4 Требований требования к мерам и средствам защиты информации, применяемым в АСУ, устанавливаются заказчиком на этапе формирования требований к защите информации в автоматизированной системе управления.

    В процессе проектирования АСУ разработчиком должно быть выбрано ПО, соответствующее требованиям в части разработки ПО.

    В случае отсутствия возможности использования указанного ПО разработчиком системы защиты АСУ должны быть реализованы компенсирующие меры, связанные с применением недоверенного ПО, в соответствии с пунктом 22 Требований

    Согласно п.18.14 Приказа №31 контроль принимаемых мер по выявлению, анализу и устранению уязвимостей программного обеспечения осуществляется Заказчиком и (или) Оператором АСУ. Каким образом, выполняется данное требование, в случае, когда Заказчиком или Оператором АСУ не осуществляется разработка прикладного ПО, а используется прикладное ПО (SCADA-пакеты, СУБД, исполнительные системы ПЛК и т.д.) сторонних разработчиков?

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

    Кроме того, при приобретении стороннего ПО необходимо предусмотреть процедуру запроса документов, подтверждающих тестирование ПО на уязвимости при разработке

    Что мы получаем в итоге?

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

    Белых пятен в Приказе №31 становится все меньше. А какие белые пятна для вас были/есть в Приказе №31? С полной версией ответа ФСТЭК России можно ознакомиться здесь.

    www.ec-rs.ru

    Приказ о разработке программного обеспечения

    Привет, Хабр. Меня зовут Владимир Разуваев, я руководитель департамента бизнес-консалтинга. Наша команда занимается тем, что помогает клиентам понимать значимость программных активов и управлять ими. В этом посте я предлагаю поговорить о внутренних разработках, которые в той или иной мере есть практически в любой компании.

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

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

    Пять шагов к формализации внутренних разработок

    Под формализацией мы имеем в виду прежде всего надлежащее документальное оформление созданного результата интеллектуальной деятельности. Нужно чётко понимать, что в соответствии с действующим законодательством авторское право на программу для ЭВМ возникает с момента ее создания в силу самого факта её создания. Справедливо, что если сотрудник, работающий в организации по трудовому договору, занимается разработкой программного продукта для компании, то данный программный продукт должен принадлежать компании, поскольку это относится к его обязанностям, и именно за это он получает заработную плату и иные виды компенсации (премии и другие выплаты компенсационного характера). Однако крайне важно понимать, что в авторском праве разграничены две вещи — авторское право (нематериальное) и т.н. исключительное право (материальное право, право распоряжаться объектом авторского права). И если авторское право возникает в силу создания и принадлежит физическим лицам, создавшим продукт, то «материальное» право подлежит тонкой документальной настройке. Механизм по защите внутренних разработок включается в пять шагов.

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

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

    Не страшно, если вы не составляли служебное задание на предыдущих этапах разработки. Ваш продукт наверняка дорабатывается, и начать практику заданий имеет смысл при развитии продукта. В этом случае сформулируйте задание так, чтобы из контекста было понятно: дорабатывается именно существующее решение, работа над которым велась и ранее. Если служебные задания так или иначе были сформулированы, нелишним будет провести их аудит – либо самостоятельно, либо с помощью привлеченного консультанта. Это позволит понять, все ли в порядке с документами, если нет, то привести их в порядок. Нужно понимать, что собственный софт, не имеющий документов, проверяющими органами будет восприниматься как пиратский. А это – лишние риски, которые ни к чему любой компании.

    Шаг третий. Сделайте так, чтобы разработчик (если он один) или тим-лидер (если у вас отдел разработки) подготовили вам докладную записку о выполнении служебного задания. В ней содержится информация о функциональности разработанного модуля, либо о функциональности продукта в целом. Также в обращении должен быть тезис о том, что программный продукт к эксплуатации готов. Фактически докладная записка фиксирует документально факт выполнения служебного задания и представляет собой аналог акта приёма-передачи.

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

    Шаг пятый. После приказа по организации о том, что продукт введен в эксплуатацию, следует подготовить распоряжение о постановке ПО на бухгалтерский баланс, определить его начальную стоимость, полезный срок использования и пр. Как это сделать? Необходимо создать экспертный совет, который в рамках обсуждения функциональности ПО выдаст рекомендации и оценки, связанные со стоимостью программного обеспечения. Рекомендации экспертов лучше формулировать в виде протокола, который затем должен быть передан в бухгалтерию. Начальная стоимость определяется самостоятельно компанией-разработчиком и чаще всего включает в себя непосредственно прямые затраты. Не стоит завышать стоимость ПО, т.к. после постановки на бухгалтерский учет компания должна будет платить налоги, которые будут зависеть от начальной стоимости. Подробные правила формирования в бухгалтерском учете и бухгалтерской отчетности информации о нематериальных активах организаций устанавливает ПБУ 14/2007 (Положение по бухгалтерскому учету «Учет нематериальных активов», приложение к приказу Минфина РФ от 27.12.2007 №153н).

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

    1. Служебное задание
    2. Докладная записка о выполнении задания
    3. Акт приемки программного продукта к эксплуатации в компании
    4. Распоряжение о постановке программного обеспечения на бухгалтерский баланс

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

    На Хабре неоднократно поднимался вопрос о важности регистрации приложений в Роспатенте. На мой взгляд, это весьма желательно, поскольку свидетельство Роспатента описывает не программный продукт как таковой, а совокупность его характеристик, определяющие его ценность для пользователя. Вложив деньги и время в защиту приложения, вы можете в какой-то степени обезопасить свою разработку от повторения. Важно: Роспатент при регистрации производит формальную экспертизу поступившей заявки, но не производит детальную экспертизу программного продукта. Поэтому правильное составление заявки на интеллектуальную защиту программного продукта – действительно другая история. При этом отмечу, что в соответствии с действующим законодательством России государственная регистрация программы для ЭВМ не является обязательной. То есть нельзя сказать, что если вы не зарегистрируете программу для ЭВМ в Роспатенте, то не сможете защитить свои права на неё, т.к., повторюсь, авторское право возникает в силу создания продукта, а не в силу его регистрации где бы то ни было.

    На что может рассчитывать рядовой разработчик?

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

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

    Почему важна бумажная работа?

    Мне и моим коллегам нередко приходится сталкиваться с ситуацией, когда собственник или топ-менеджеры компаний-заказчиков даже не знают, какое ПО и для каких целей создала команда разработки. Информацию о таком софте мы получаем на самом первом этапе процедуры Software Asset Management, когда специальные средства сканируют серверы и ПК в компании-заказчике. Обнаружив такие «артефакты», мы вместе с ответственными сотрудниками поднимаем необходимую документацию и по крайней мере понимаем, что перед нами внутренняя разработка.

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

    Если остались вопросы – пишите в комментариях, я постараюсь ответить.

    m.habr.com

    Это интересно:

    • Официальным опубликованием закона считается первая публикация его Федеральный закон от 14 июня 1994 г. N 5-ФЗ "О порядке опубликования и вступления в силу федеральных конституционных законов, федеральных законов, актов палат Федерального Собрания" (с изменениями и дополнениями) Федеральный закон от […]
    • Вор закон в тюмени Драматичный поворот в судьбе тюменского "вора в законе". Неделю назад была поставлена жирная точка в "воровской" карьере 56-летнего жителя Тюмени Юрия Тишенкова, более известного в криминальных кругах по кличке Ганс. Известные […]
    • Вогоип приказ 6 Вогоип приказ 6 МИНИСТЕРСТВО ВНУТРЕННИХ ДЕЛ РОССИЙСКОЙ ФЕДЕРАЦИИ от 10 сентября 2002 года N 872 О назначении руководства оперативных групп ВОГОиП МВД России в Чеченской Республике Во исполнение приказов МВД России от 30 октября 1999 […]
    • Уголовный кодекс рф статья 238 Статья 238. Производство, хранение, перевозка либо сбыт товаров и продукции, выполнение работ или оказание услуг, не отвечающих требованиям безопасности Информация об изменениях: Федеральным законом от 9 июля 1999 г. N 157-ФЗ […]
    • Закон военнослужащего по контракту Порядок предоставления отпусков военнослужащим по контракту Порядок предоставления отпусков военнослужащим, проходящим военную службу по контракту, регламентирован статьей 11 Федерального закона от 27 мая 1998 года № 76-ФЗ «О […]
    • Законе о налоге на прибыль Закон РФ от 27 декабря 1991 г. N 2116-I "О налоге на прибыль предприятий и организаций" Информация об изменениях: Федеральными законами от 30 ноября 1995 г. N 188-ФЗ, от 27 декабря 1995 г. N 211-ФЗ и от 31 декабря 1995 г. N 227-ФЗ в […]