Garantizar procesos de gestin de configuracin de Software para entorno

de desarrollo de software de seguridad nuclear

I-Hsin Chou

Investigacin del Instituto de Energa Nuclear, el Consejo de energa atmica, P.O. Box 3-11, pulmn-Tan, 32525 Tao Yuan, Taiwn, ROC

un t r i e l c i f n o b s t r a c t

Historia del artculo:
Recibido 06 de octubre de 2010
Recibido en forma revisada el 11 de junio de 2011
Aceptado 18 de junio de 2011 en
lnea disponible del 13 de julio de
2011
La principal diferencia entre el software genrico y nuclear es que el factor de riesgo es infinitamente mayor en software
nuclear si hay un fallo en el sistema de seguridad, puede provocar importantes prdidas econmicas, dao fsico o amenaz
la vida humana. Sin embargo, el entorno de desarrollo de software seguro a menudo han sido ignorados en la industria nucle
En respuesta a los ataques terroristas del 11 de septiembre de 2001, Comisin Reguladora Nuclear estadounidense (USNRC
la gua del regulador (RG 1.152-2006) '' Criterios revisados para el uso de las computadoras en los sistemas de seguridad de
centrales nucleares '' para proporcionar directrices especficas de seguridad durante todo el ciclo de vida de desarrollo de
software. Gestin de configuracin de software (SCM) es una disciplina esencial en el entorno de desarrollo de software. SC
implica identificar elementos de configuracin, controlar cambios a aquellos artculos y mantener la integridad y trazabilida
de ellos. Para asegurar el software de seguridad nuclear, este trabajo propone un seguro SCM procesos (S 2CMP) que infund
requisitos de seguridad reglamentarios en propuesta procesos SCM. Por otra parte, un diagrama de flujo de proceso (PFD) s
adopta para describir S2CMP, que pretende mejorar la comunicacin entre los reguladores y los desarrolladores.

Palabras clave:
Entorno de desarrollo de software de seguridad nuclear

Gestin de la configuracin de software

Requisito de seguridad

2011 Elsevier Ltd. Todos los derechos reservados.

1. Introduccin
Gestin de configuracin de software (SCM) se refiere al control de la evolucin de los
sistemas de software complejos. SCM es un proceso que consiste en identificar
elementos de configuracin (CIs), control de cambios en los elementos de configuracin
y mantenimiento de la integridad y trazabilidad de la CEI a lo largo del ciclo de vida de
desarrollo de software (SDLC). El CIs incluyen productos de software de trabajo
entregados a los clientes y elementos necesarios para crear los productos de software de
trabajo como documento de diseo de software, documento de prueba, datos de prueba
y compilador. La importancia de la SCM est dirigida tambin por modelos de mejora
de procesos software, como Capability Maturity Model (CMM), integracin de modelo
de madurez de capacidad (CMMI) y mejora de procesos Software y determinacin de
capacidad (especia), en que SCM procesos desempean un papel importante en el logro
de un nivel inicial de madurez (Krikhaar, 2007).

Durante la ltima dcada, sistemas de seguridad ms nucleares han sido mejorados de

hardware-sistemas softwarebased sistemas. Aunque hay muchas ventajas que ofrece el
nuevo diseo basado en software, todava hay algunos inconvenientes. Uno de los
inconvenientes es el tema del control del CIs desde el entorno de desarrollo o
funcionamiento. Segn el informe del Instituto de Energa Nuclear operacin (INPO) en
2008: en los ltimos cinco aos, se produjeron 17 CN gritos y ms de

1,6 millones horas MW de generacin se

Tel.: + 886 3 4711400 x 6368; fax: + 886 3 4711415. Direccin perdieron cuando software
de correo electrnico: ihsin@iner.gov.tw

fallas producen transitorios inesperados

0306-4549 / $ - ver frente importa 2011 Elsevier Ltd. Todos los derechos
reservados. o equipo respuestas; 36% de los eventos
de software estn relacionados con SCM
doi: 10.1016/j.anucene.2011.06.016
(Instituto de operaciones de Energa
Nuclear, 2008de). Organismo internacional de energa atmica (OIEA) incidente
Reporting sistema (IRS) tambin muestra que en promedio el 25% de NPP registrado
eventos fueron causado por deficiencias o errores de configuracin (laAgencia
Internacional de energa atmica, 2003). Hay algunos relacionados con SCM cdigo
de Federal regulaciones (CFR) y gua regulador (RG) para sistema de la seguridad
nuclear, como 10CFR 55, 10CFR 21.51, 10CFR 50 Apndice A, 10CFR 50 Apndice
B, 1.168 RG, 1.173 RG y RG 1.169. Sin embargo, estos reglamentos no especifican
pasos e instrucciones detalladas. Afortunadamente, RG 1.169'' planes de gestin de
configuracin para el software de ordenador digital utilizado en sistemas de seguridad
de centrales nucleares '' declara apoyar IEEE 828-'' estndar de IEEE para planes de
gestin de configuracin Software'' y IEEE 1042-'' IEEE estndar para gestin de
configuracin ''. En de Chou (Chou y Fan, 2006) artculo, requisitos funcionales y
requisitos no funcionales de SCM se identificaron a partir de los tres recursos de
reglamentacin nucleares: rea de proceso de gestin de configuracin (CM) de
CMMI, reglamentos de uso y estndares IEEE relacionados con SMC. Las
descripciones ms detalladas se discutir en la seccin 2.1.

Ontheotherhand,themovetousingInformationTechnology(IT) productos tales como

previamente desarrollaron un software, los productos comerciales de estndar (COTS)
y normativa como Ethernet y TCP/IP permite a los iniciados malintencionados se
aproveche de la ignorancia en la industria. El resultado es un nmero creciente de
incidentes de seguridad que afectan la seguridad de la planta de Energa Nuclear
(NPP) y el progreso de las industrias nucleares. Algunos eventos de seguridad contra
CN han divulgado pblicamente. Un gusano informtico complejo-'' Stuxnet'' ha
infectado los ordenadores personales de personal de la primera central nuclear de Irn,
informado la agencia oficial de noticias IRNA (noticia de la BCC, 2010). En el CN de
Oconee de Carolina del Sur (noviembre de 2008), un mensaje de la seal transmitida
con de datos de rango dio lugar a la falta de un sistema digital que no esperaba recibir
un mensaje de tiempo errneo de esa manera. En marzo de 2008, acceso inadvertido
por el personal de planta a un sistema digital a travs de una conexin de LAN dos
vas causado la portilla CN unidad 2 sistema comportarse inesperadamente (David,
2010). Por otra parte, la Agencia Internacional de energa atmica (OIEA) tambin
anunci en un comunicado que se fue desarrollando nuevas directrices con el objetivo
de la lucha contra el peligro de ataques computarizados por fuera intrusos o personas
corruptas (Kevin, 2004). Sin embargo, el incidente anterior informes hicieron
impactos seguridad no claramente establecidos directamente en el entorno de
desarrollo de software.

Aunque los informes de seguridad pblicos de CN son insuficientes para analizar los
impactos de la seguridad en SCM, amenazas a la seguridad tambin podran provenir
de los iniciados o forasteros en entorno de desarrollo de software. Hay tres amenazas
potenciales fueron identificadas desde la perspectiva SCM (David, 2005):

(1) Forasteros sin privilegios: un forastero (no un desarrollador o administrador)

puede intentar leer o modificar activos (software fuente cdigo o historia
informacin) cuando no estn autorizados a hacerlo. Sistemas de entorno de
desarrollo de software deben apoyar autorizacin (como sistemas de inicio de
sesin) y definir de qu no autorizados pueden hacer los usuarios. Por otra parte,
los usuarios no autorizados no se debe modificar un repositorio de cdigo fuente.

(2) Los desarrolladores de sin malvolo con privilegios: el entorno de desarrollo de

software debe admite inicios de sesin protegidas (por ejemplo, si utiliza
contraseas, deben proteger las contraseas durante el trnsito y mientras estn
almacenados). Una vez que los usuarios se autentican, un SCM debe ser capaces
de limitar qu usuarios pueden basado en la autorizacin que se concede. Limitar
la escritura de archivos especficos dentro de un proyecto puede ser mucho ms
til para los desarrolladores que no.

(3) Los desarrolladores de malicioso con privilegios: un desarrollador

malintencionado puede insertar intencionalmente Trojan caballos en programas
de software. No es fcil distinguir un desarrollador autorizado de un atacante que
se adquirieron las credenciales de un desarrollador autorizado. Un desarrollador
malintencionado incluso podra intentar hacer que parezca que otros
desarrolladores ha hecho un acto malintencionado. Podra intentar modificar los
datos o insertar cdigo malicioso por lo que parece que alguien ms hizo el
cambio. Hay algunos mecanismos SCM que pueden usarse contra ellos; como
asegurndose de que todas las acciones de desarrollo puede ser fcilmente
revisado ms adelante, apoyando control automatizado antes de aceptacin,
incluyendo la deteccin de cambios sospechoso/malicioso, grabacin cambio y
requieren de comentarios de otro desarrollador.

Este documento est organizado como sigue. Seccin 2 presenta las guas reguladoras
de SCM y software de seguridad y normativa nuclear. En la seccin 3, una segura
procesos de gestin de configuracin de Software (S2CMP) se propone asegurar el
entorno de desarrollo de software. Un diagrama de flujo de proceso (PFD) se emplea
para presentar S2CMP en seccin 4. Por ltimo, se dan algunas conclusiones y trabajo
futuro en seccin 5.
 2. Requerimientos regulatorios nucleares
relacionados
2.1. nucleares reglamentos y lineamientos normativos para SCM

La energa nuclear industria desarroll e implement un programa de aseguramiento

de calidad para todos los aspectos de diseo, fabricacin, construccin,
documentacin y operacin de componentes y sistemas relacionados con la seguridad.
ASME NQA-1-1989 proporciona el requisito de programa de aseguramiento de la
calidad y requisitos de SCM son parte de la garanta de calidad total. En 10 CFR parte
50, '' nacional licencias de instalaciones de produccin y utilizacin,'' prrafo
55a(a)(1) requiere, en parte, que los sistemas y componentes diseados, probados y
examinados a los estndares de calidad acordes con la funcin de seguridad a realizar.
Criterio 1, '' normas y registros de calidad,'' del Apndice A, '' General diseo criterios
para centrales nucleares,'' de 10 CFR Part 50 requiere, en parte, 1 que se mantenga
registros adecuados de diseo y pruebas de sistemas y componentes importantes para
la seguridad por o bajo el control del titular de unidad de energa nuclear a lo largo de
la vida de la unidad. 10CFR 50 Apndice B, '' calidad aseguramiento criterios para
plantas de energa y combustible reprocesado centrales nucleares,'' a 10 CFR Part 50
describe criterios que deben cumplir un programa de aseguramiento de calidad para
sistemas y componentes que prevenir o mitigacin las consecuencias de los accidentes
postulados. Por otra parte, RG 1.169-'' planes de gestin de configuracin '' tambin
apoyar estndares como IEEE IEEE 828-1998'' estndar de IEEE para planes de
gestin de configuracin Software'' 1042-'' IEEE estndar para gestin de
configuracin '' (IEEE Std, 1987). En trabajos anteriores de Chou (Chou y Fan, 2006),
cada elementos especficos de regulacin especificacin SCM fueron mapeadas a
caractersticas funcionales o no funcionales. Caractersticas funcionales incluyen las
funciones bsicas de la SCM, como identificacin de la configuracin, control de
configuracin, estado contabilidad, auditora y revisin, gestin de flujo de trabajo e
interfaz grfica web. Caractersticas no funcionales incluyen la trazabilidad,
integracin de informacin y mantenimiento de la consistencia.

2.2. nucleares reglamentos y lineamientos normativos para la seguridad del software

I. 2176-H. Chou / anales de la Energa Nuclear 38 (2011) 2174-2179

El Reglamento en 10 CFR 50.55a (h) requiere que los sistemas de proteccin para
centrales nucleares requisitos IEEE Std. 603-1991 y la hoja de correccin de fecha 30
de enero de 1995. Con respecto al uso de las computadoras en los sistemas de
seguridad, 74.3.2-2003 de Std. de la IEEE (IEEE Std, 2003) especifica los requisitos
especficos de la computadora para complementar los criterios y requisitos de IEEE Std.
603-1998, '' criterios estndar para sistemas de seguridad para estaciones de generacin
de Energa Nuclear''. Clusula 5.9, '' Control de acceso,'' de IEEE Std. 74.3.2-2003 se
refiere a los requisitos de la clusula 5.9 de IEEE estndar 603-1998, que dice, '' el
diseo debe permitir el control administrativo de acceso a equipo de sistema de
seguridad. Sin embargo, IEEE Std. 7-4.3.2-2003 no proporciona ninguna orientacin
adicional para el sistema computadora-basado equipo y sistemas de software para
abordar los requisitos de control de acceso de IEEE-603-1998 de clusula 5.9 o los
requisitos de independencia de la clusula 5.6.3. En consecuencia, la USNRC
modificado 1.152 Gua reguladora '' criterios para el uso de las computadoras en los
sistemas de seguridad de plantas de energa nuclear'', revisin 2, incluir posiciones
reglamentarias que ofrecen orientacin especfica sobre la proteccin de las fases de
diseo y desarrollo de sistemas de seguridad basados en computadoras, destinado a
abordar los criterios dentro de estas clusulas (RG 1.152, 2006). Rg1.1522006 utiliza la
cascada de las fases del ciclo de vida como marco para describir la direccin de
seguridad del sistema. El marco consta de nueve fases de las secciones 2.1 a 2.9 que
incluyen conceptos, requisitos, diseo, implementacin, prueba, instalacin de
verificacin, prueba, de la aceptacin la operacin, mantenimiento y retiro de la fase.
Chou y Fan (2010) propuso diez actividades de seguridad, que se agrupan en tres
etapas: etapa, fase de desarrollo y etapa de aplicacin de la planificacin. Diez
actividades de seguridad se compone de planificacin, anlisis de requisitos, diseo de
seguridad, implementacin de seguridad, prueba de instalacin, mantenimiento de la
seguridad, operacin de seguridad, cierre de seguridad y aseguramiento de la calidad de
la seguridad. Cada actividad de seguridad corresponde a cada etapa de las fases de
desarrollo de software.

3. Garantizar procesos de gestin de

configuracin de Software (S2CMP)
Basado en los requisitos regulatorios nucleares anteriores, este trabajo propone un
proceso seguro de SCM (S2CMP) para asegurar el entorno de desarrollo de software.
Como se describe en figura 1, hay dos partes principales en S2CMP: procesos de SCM
(SCMP) y actividades de seguridad (SA). SCMP (el lado izquierdo del 1 Fig.)
representa un ciclo de vida propuesto de SCM con cinco fases incluyen:
institucionalizado, planificacin, mantenimiento de lnea de base (BM), cambiar
management (CM) y auditora & fase contable (AA). Por otra parte, un proceso de
control de cambios iterativos se compone de fase BM, AA fase y fase de CM. Cada fase
contiene algunas actividades SCM y la seguridad que la referencia a los requisitos
regulatorios nucleares anteriores. Por otra parte, SA (la derecha de figura 1) contiene
tres grupos con siete actividades de seguridad para apoyar SCMP. Las descripciones
detalladas de SCMP y SA se describen como abajo.

3.1. fase institucionalizado

3.1.1. actividades SCM

Institucionalizada fase se utiliza para apoyar las actividades SCM, que incluyen tareas y
asignacin de grupo, medio ambiente construccin y tareas de formacin de equipo
necesitan llevar a cabo.

(1) Tarea y asignacin de Grupo: en esta actividad, se identifican representantes del

SCM/SCCB equipo de equipo de SCM y tablero de Control de configuracin de
Software (equipo de SCCB). En otras palabras, SCCB equipo y equipo de SCM
deben trabajar juntos. Por ejemplo, los representantes del equipo de SCM son
responsables de gestionar y controlar el estado de una solicitud de cambio.
Cualquier actualizacin de solicitudes y bases de software se realiza bajo autoridad
del equipo de SCCB. Cualquier peticin de cambio levantada debe ser
 documentado y enviada al equipo de SCM/SCCB. El equipo SCM/SCCB trabaja
con el SCCB para una evaluacin de la solicitud de cambio.

(2) Construccin de entorno: un entorno de desarrollo de SCM debe construirse, como

herramientas de SCM, consistencia comprobando software, analizador de impacto
y repositorio SCM.

(3) Equipo de entrenamiento: todos los miembros del equipo SCM/SCCB deben
asignarse al asistir a cursos de formacin.

3.1.2. las actividades de seguridad

(1) Asignacin de equipo de seguridad: equipo de seguridad es responsable de

mantenimiento de la seguridad, que evala el efecto de los cambios propuestos,
procedimientos operativos para cumplir con el uso evala y analiza los riesgos de
seguridad que afectan a la titular de la licencia y el sistema. El cambio de los
datos y la introduccin en el mecanismo de seguridad debe llevarse a cabo bajo
control del software mantenimiento medio.
(2) Evaluacin de la seguridad: el objetivo principal de la evaluacin de seguridad es
identificar potenciales vulnerabilidades de seguridad en las fases relevantes del
ciclo de vida de software. Estos procesos de evaluacin de la seguridad son
similares a RAMCAP (anlisis de riesgo y gestin para la proteccin de activos
crticas): caracterizacin de activos, caracterizacin de amenaza, anlisis de
consecuencia, anlisis de vulnerabilidad, evaluacin de amenazas, evaluacin de
riesgos y gestin de riesgos. RAMCAP es un marco para analizar y gestionar los
riesgos asociados con los ataques terroristas contra los activos de infraestructura
crtica como transporte, telecomunicaciones, energa elctrica, abastecimiento de
agua y as sucesivamente. La industria nuclear tambin fue seleccionada como
uno de los anlisis de riesgo inicial y gestin para los sectores de proteccin de
activos crticos (RAMCAP) (David et al., 2007). Sin embargo, la actividad de
evaluacin de seguridad de este documento se centra en asegurar el entorno de
desarrollo de software nuclear. Existe un similar enfoque RAMCAP para la
planta de energa nuclear; los lectores pueden encontrar las descripciones ms
detalladas en 5,71 gua reguladora: programa de seguridad ciberntica para
instalaciones nucleares (RG 5,71, 2010).
(3) Equipo de entrenamiento: todos los miembros del equipo de seguridad deben ser
asignados para asistir a cursos de formacin.

3.2. Fase de planificacin

3.2.1. actividades SCM

En esta fase, deben ser un plan SCM y un procedimiento SCM

producto

(1) preparacin de la planificacin SCM: plan A SCM debe incluye contenidos como
sigue:

Identifica SCM relacionados con regulaciones.

 Identifica las responsabilidades y autoridades para la gestin y cumplimiento de
las actividades previstas de la SCM.

Figura 1. Resumen de procesos de gestin de configuracin de Software seguro.

Identifica todas las actividades a realizar en la aplicacin del proyecto.

Identifica la necesaria coordinacin de las actividades SCM con las otras

actividades en el proyecto.

Identifica herramientas y fsica y recursos humanos necesarios para la ejecucin

del plan.

Identifica cmo el plan se mantendr actual mientras que, en efecto.

(2) preparacin de un procedimiento SMC: basado en el plan SCM, un

procedimiento SCM aborda pasos ms detallados para el control de cambio de
software, tales como solicitud de cambio, cambiar revisin, proceso de
evaluacin, cambiar estado, cambiar el informe contable y de auditora y
verificacin.

3.2.2. las actividades de seguridad

Identificacin de elementos de seguridad: el resultado de la evaluacin de la seguridad
se utiliza para identificar elementos de seguridad, como interfaces de red, restriccin
de arquitectura, configuracin de software y seguridad de rendimiento funcional. En
la industria nuclear, sistema de seguridad realiza las funciones de seguridad tales
como viaje de reactor, ingeniera de seguridad u otras funciones apoyo auxiliares.
Debe ser separado de las funciones de la inseguridad. Cualquier ataque o falla del
sistema de seguridad no, sistema de comunicaciones o datos transmitidos por el
sistema de seguridad no no debera influir en la determinacin de seguridad
independientes. Por lo tanto, hay algunas interfaces de red (o caminos) de la red
relacionadas con la seguridad se identifican como elementos de seguridad, que incluye
la empresa red, red de control basada en IP, red de controlador lgico programable
(PLC) y as sucesivamente. Adems, punto de entrada remota es otro ejemplo de
elemento de seguridad para el diseo de arquitectura restriccin. Su principal objetivo
es evitar fuera intrusos de otra red de comunicacin externa. Adems, esta actividad
est diseada para apoyar la tarea de preparacin del plan de SMC y SMC
procedimiento. Por lo tanto, los elementos de seguridad tambin deben definirse en el
plan de SMC y SMC procedimiento.

3.3. fase de mantenimiento de la base

3.3.1. actividades SCM

Mantenimiento de lnea de base: en esta actividad, se cre, definidos lneas de base.
Tambin un repositorio SCM se construir para el almacenamiento de instantneas. El
rea del repositorio de base de podra ser dividido en dos partes: biblioteca y la
biblioteca de fuente del documento. Antes de cada creacin de lnea de base, debe
publicarse un informe lnea de base. Los miembros del equipo SCM/SCCB revisin el
informe de lnea de base para asegurar la exactitud de los contenidos de la lnea de
base y comprobar si los contenidos cumplen el propsito de la lnea de base antes de
la creacin de la lnea de base. Segn CEI figuran en los informes de lnea de base
como horario previsto, se crear una lnea de base. En cada creacin de lnea de base,
SCM/SCCB equipo crea instantneas de documentos cdigo de andsource.
Thebaseline ofdocumentsis un archiveor conjunto ofapproved documentos que
satisfacen el propsito inicial. Por lo tanto, esta actividad puede apoyar software de
diseo, implementacin, prueba y final liberacin dentro del entorno de desarrollo de
software.

3.3.2. las actividades de seguridad

Verificacin del diseo de seguridad: para garantizar la seguridad elementos de

configuracin haba sido considerado en la especificacin del software, equipo de
seguridad est diseado para apoyar el mantenimiento de la lnea de base del proceso
SCM. Sin embargo, el mantenimiento de lnea de base tambin es asignado para
apoyar el diseo de software. En otra palabra, esta seguridad activa soporte software
de diseo indirectamente.

3.4. fase de gestin de cambio

3.4.1. actividades SCM

(1) Cambio de software revisin: procedimiento SCM es el ms importante para esta

fase. Cualquier cambio de software debe seguir procedimiento SCM y realizar
revisin cambio por equipo SCM/SCCB.

El equipo SCM/SCCB puede identificar un especialista evaluar y dar comentarios

sobre la solicitud. El resultado de la evaluacin tales como rechazar, aceptan, o an
no sern registrados como el cambio solicitar estado y regres al titular de la
solicitud de cambio y al equipo del proyecto por el equipo SCM/SCCB. Anlisis de
impacto deben incluir anlisis de diagrama de flujo de datos, anlisis de
dependencia y anlisis de la interfaz. Si alguno cambia las solicitudes sobre
relacionadas con la seguridad, un informe de anlisis de seguridad debe escuchar
antes de cambio.

(2) Cambio de software verificacin: despus de que fue aprobado el cambio

solicitado, el desarrollador comienza a modificar el diseo de software en cdigo,
estructuras de base de datos y representaciones ejecutables relacionados con
 mquina. Entonces, SCM/SCCB equipo verificar software modificado para el
cambio de diseo correcta, exacta y completa.

3.4.2. las actividades de seguridad

(1) Cambio de seguridad informe: esta actividad est diseada para apoyar la revisin
de cambio de software de proceso SCM. El equipo de seguridad se centra en el
control de revisin y cambio de tem de configuracin de seguridad. En otras
palabras, equipo de seguridad debe apoyar SCM/SCCB equipo para evaluar el
impacto de cambios en la seguridad. Por lo tanto, el mtodo de evaluar los cambios
de seguridad se basa en el anlisis del impacto de ver el cambio de software
(consulte la seccin 3.4.1). Adems, revisin de cdigo independiente puede usarse
tambin para lograr ms seguro.

(2) Verificacin de implementacin de seguridad: el equipo de desarrollo transforma

el diseo de software en cdigo, estructuras de base de datos y relacionadas con
representaciones ejecutables de la mquina. Puede que necesiten herramientas de
anlisis esttico para detectar vulnerabilidades comunes, defectos de ejecucin y
errores de cdigo fuente. En esta actividad, se asigna el equipo de seguridad para
garantizar que la transformacin del diseo es correcta, exacta y completa. Equipo
de seguridad debe aplicar herramientas de anlisis esttico para detectar
vulnerabilidades comunes, defectos de ejecucin y errores de cdigo fuente. Al
mismo tiempo, el resultado de la verificacin tambin se utiliza para apoyar el
proceso de SMC (es decir, verificacin de cambio de software). El equipo de
seguridad apoyar el software de integracin y prueba de aceptacin de fbrica.
Adems, debe tambin aseguran la correccin de las caractersticas de seguridad
fsica y lgica de software de seguridad en el ambiente objetivo.

3.5. auditora y contabilidad

3.5.1. Actividades SCM

2178 I.-H. Chou / anales de la Energa Nuclear 38 (2011) 2174-2179

De auditora y contabilidad: en general, hay dos tareas de auditora deben ser realizada
(IEEE Std, 1987): auditora de configuracin fsica (PCA) y auditora de configuracin
funcional (FCA). La porcin PCA de la auditora consiste en determinar que todos los
elementos se identifican como parte de la configuracin estn presentes en la lnea de
base. La auditora tambin debe establecer que la versin correcta y la revisin de cada
parte estn incluidos en la base del producto y que corresponden a la informacin
contenida en el informe de estado de configuracin de la lnea de base. La porcin de
FCA es similar, en que alguien reconoce haber inspeccionado o probar cada elemento
para determinar que cumple las funciones definidas en las especificaciones o s para el
cual fue desarrollado. Los objetivos de una PCA/FCA son para que los desarrolladores
para proporcionar aviso que obligaciones contractuales estn a punto de finalizar y para
proporcionar pruebas suficientes para los clientes o la organizacin del usuario para
aceptar el producto e iniciar la transicin en uso operacional. Una lnea de base se
considera como aprobado para ms utilizado despus de que el equipo SCM/SCCB
considera que el informe de auditora de lnea base se ha completado. Adems,
SCM/SCCB equipo produce peridicamente informes SCM para informar las
actividades SCM actualizadas a los miembros del proyecto, el equipo SCM/SCCB y los
grupos afectados. Cualquier defecto del cambio de software se encuentra que deben
reenviar a la fase de mantenimiento de lnea de base (seccin 3.3) y cambiar la fase de
gestin (seccin 3.4).

3.5.2. Actividades de seguridad

Seguridad auditora y contabilidad: en esta actividad, el equipo de seguridad debe

apoyar la prueba de la funcin de seguridad. Deberan de hacer asegurar la correccin
de caractersticas de seguridad de software. Adems, el equipo de seguridad debe
apoyar la auditora y la tarea contable de SCM. Su principal objetivo es asegurar que las
vulnerabilidades internas y externas no se han introducido en el software de
modificaciones. Por ltimo, equipo de seguridad somete peridicamente cambio las
estadsticas sobre seguridad SCM/SCCB equipo para el software cambian informe
contable. Los problemas se encuentran en esta actividad debe ser la fase de
mantenimiento de la base de volver a introducir (seccin 3.3) y cambiar la fase de
gestin (seccin 3.4).

4. Funciones y diagrama de flujo de

proceso (PFD) para garantizar los
procesos de gestin de
configuracinProteccin
Un buen programa SCM no slo debe proporcionar procesos de cambio de software
sino tambin debe apoyar las actividades de seguridad para asegurar la calidad del
entorno de desarrollo de software. Los roles definidos aqu constituyen un complemento
a las funciones de gestin del software existentes (gestin de proyectos). La diferencia
es que esos roles se centran ms especficamente en las actividades de seguridad.

De hecho, existen tres roles en S2CMP (ver la parte superior de figura 2):
desarrollador, SCM/SCCB equipo y equipo de seguridad. Cada columna representa
las actividades de papel en S2CMP. Por ejemplo, la primera columna representa las
fases de desarrollo de software de diseo de concepto a la versin de software; la
segunda columna representa nueve Teamactivities SCM/SCCB en SCMP desde la
fase institucionalizada a la auditora y la fase de contabilidad; la tercera columna
representa el equipo de seguridad con siete actividades de seguridad SCM/SCCB
equipo de apoyo. La Asociacin representa las relaciones entre estas actividades.
Solicitud de cambio y flujo de trabajo se utilizan para expresar el proceso de solicitud
de cambio de software y la secuencia de actividades. Por ejemplo, la '' identificacin
de elemento de seguridad '' de las actividades de seguridad apoya la '' preparacin de
plan SCM'' de las actividades SCM y la '' preparacin de plan SCM'' tambin est
diseada para apoyar el '' anlisis de requisito '' en las fases de desarrollo de software.
Despus de que la solicitud de cambio de software es propuesta por el desarrollador,
SCM/SCCB equipo y equipo de seguridad apoyarn revisin de cambio de software y
revisin de seguridad respectivamente.
5. Conclusin y trabajo futuro

Figura 2. Diagrama de flujo de proceso (PFD) para procesos de gestin de configuracin de Software seguro.

Histricamente, la seguridad es raramente considerada por ingenieros de software como

una disciplina esencial en el desarrollo de software envi-
 ambiente. Por lo tanto, ingenieros de software por lo general no son conscientes de las
vulnerabilidades de seguridad y las tcnicas para protegerse de las amenazas. Como
resultado, software defectuoso hace varios miles de millones de dlares US de
prdidas econmicas cada ao en todo el mundo (Robert, 2005). De la misma manera,
como se ha adoptado la tecnologa digital para desarrollar sistemas de seguridad
nuclear, seguridad tambin se ha convertido en un tema importante para la industria
nuclear.

Frente a nuevos retos de seguridad, USNRC emiti la nueva versin de RG 1.152-

2006, que proporciona las caractersticas de sistema especfico y orientacin de las
actividades de desarrollo relativas a la seguridad de sistema de seguridad
computarizado (cyber). Sin embargo, todava hay ninguna hoja de ruta clara para
inducir a requisitos de seguridad en el SCM existente. Este trabajo propone una
S2CMP que pretende combinar las actividades de seguridad de la regulacin en el
proyecto procesos SCM. Las aportaciones de este trabajo se muestran a continuacin:

(1) S2CMP es un proceso hbrido basado tanto en el Reglamento de SCMrelated

nuclear as como reglamentos relacionados con la seguridad para el entorno de
desarrollo de software de seguridad nuclear.

(2) La S propuesta2CMP hace hincapi en procesos de seguridad independiente de la

plataforma es adecuado para aplicacin a entornos y plataformas heterogneas.
Adems, ofrece un proceso de cinco fases SCM con siete actividades de
seguridad que se fusionan en el entorno de desarrollo de software existentes.

(3) Descripciones detalladas y PFD de S2CMP son tiles para los desarrolladores
2software y licenciatarios para mejor entienden los requisitos reglamentarios.
Ellos tambin mejoran la comunicacin entre el regulador y los desarrolladores.

Ms trabajo tambin es necesario proporcionar una herramienta asistida por

computadora que apoya S2CMP, as como un refinamiento del enfoque terico
demostrando S2CMP con un estudio de caso real. Adems, una base de
CC_SSE_CMM (Lee et al., 2003; ISO/IEC_JTC1/SC27, 2005) modelo de evaluacin
se considera medida S2procesos de ingeniera y desempeo de CMP en la
investigacin ms.

BER), 42-49.