Planificación de Continuidad del Negocio

Business Continuity Plan Writing Tutorial
Business continuity planning (BCP) is the creation and validation of a practiced logistical plan for how an organization will recover and restore partially or completely interrupted critical (urgent) functions within a predetermined time after a disaster or extended disruption. The logistical plan is called a business continuity plan.

In plain language, BCP is working out how to stay in business in the event of disaster. Incidents include local incidents like building fires, regional incidents like earthquakes, or national incidents like pandemic illnesses.

BCP may be a part of an organizational learning effort that helps reduce operational risk associated with lax information management controls. This process may be integrated with improving information security and corporate reputation risk management practices.

In December 2006, the British Standards Institution (BSI) released a new independent standard for BCP — BS 25999-1. Prior to the introduction of BS 25999, BCP professionals relied on BSI information security standard BS 7799, which only peripherally addressed BCP to improve an organization's information security compliance. BS 25999's applicability extends to organizations of all types, sizes, and missions whether governmental or private, profit or non-profit, large or small, or industry sector.

In 2007, the BSI published the second part, BS 25999-2 "Specification for Business Continuity Management", that specifies requirements for implementing, operating and improving a documented Business Continuity Management System (BCMS).

Contents

• 1 Introduction
• 2 Analysis
  
  
  
  • 2.1 Impact analysis (Business Impact Analysis, BIA)
  • 2.2 Threat analysis
  • 2.3 Definition of impact scenarios
  • 2.4 Recovery requirement documentation
• 3 Solution design
• 4 Implementation
• 5 Testing and organizational acceptance
• 6 Maintenance
  
  
  
  • 6.1 Information update and testing
  • 6.2 Testing and verification of technical solutions
  • 6.3 Testing and verification of organization recovery procedures
  • 6.4 Treatment of test failures
• 7 See also
• 8 References
  
  
  
  • 8.1 Notes
  • 8.2 Bibliography
• 9 Further reading
  
  
  
  • 9.1 International Organization for Standardization
  • 9.2 British Standards Institution
  • 9.3 Others
• 10 External links
  
  
  
  • 10.1 Standards organizations
  • 10.2 Competency certification ventures

A completed BCP cycle results in a formal printed manual available for reference before, during, and after disruptions. Its purpose is to reduce adverse stakeholder impacts determined by both the disruption's scope (who and what it affects to what extent) and duration (e.g., hours, days, months). Measurable business impact analysis (BIA) "zones" -- areas in which hazards and threats reside -- include civil, economic, natural, technical, secondary and subsequent.

For the purposes of this article, the term disaster will be used to represent natural disaster, human-made disaster, and disruptions.

Threat Analysis

After defining recovery requirements, documenting potential threats is recommended to detail a specific disaster’s unique recovery steps. Some common threats include the following:

• Disease [1]
• Earthquake [2]
• Fire
• Flood [3]
• Cyber attack
• Sabotage
• Hurricane [4]
• Utility outage [5]
• Terrorism [6]

All threats in the examples above share a common impact: the potential of damage to organizational infrastructure - except one (disease). The impact of diseases can be regarded as purely human, and may be alleviated with technical and business solutions. 

Testing and verification of technical solutions

As a part of ongoing maintenance, any specialized technical deployments must be checked for functionality. Some checks include:

• Virus definition distribution
• Application security and service patch distribution
• Hardware operability check
• Application operability check
• Data verification

Confiabilidad y Disponibilidad

Reliability and Availability Basics

Realtime and embedded systems are now a central part of our lives. Reliable functioning of these systems is of paramount concern to the millions of users that depend on these systems everyday. Unfortunately most embedded systems still fall short of users expectation of reliability.

In this article we will discuss basic techniques for measuring and improving reliability of computer systems. The following topics are discussed:

• Failure Characteristics
  
  
  • Hardware Failures
  • Software Failures
• Reliability Parameters
  
  
  • MTBF
  • FITS
  • MTTR
  • Availability
  • Downtime

Failure Characteristics
Hardware Failures

Hardware failures are typically characterized by a bath tub curve. An example curve is shown below. The chance of a hardware failure is high during the initial life of the module. The failure rate during the rated useful life of the product is fairly low. Once the end of the life is reached, failure rate of modules increases again. 

Hardware failures during a products life can be attributed to the following causes:

Design failures	This class of failures take place due to inherent design flaws in the system. In a well designed system this class of failures should make a very small contribution to the total number of failures.
Infant Mortality	This class of failures cause newly manufactured hardware to fail. This type of failures can be attributed to manufacturing problems like poor soldering, leaking capacitor etc. These failures should not be present in systems leaving the factory as these faults will show up in factory system burn in tests.
Random Failures	Random failures can occur during the entire life of a hardware module. These failures can lead to system failures. Redundancy is provided to recover from this class of failures.
Wear Out	Once a hardware module has reached the end of its useful life, degradation of component characteristics will cause hardware modules to fail. This type of faults can be weeded out by preventive maintenance and routing of hardware.

Software Failures

Software failures can be characterized by keeping track of software defect density in the system. This number can be obtained by keeping track of historical software defect history. Defect density will depend on the following factors:

• Software process used to develop the design and code (use of peer level design/code reviews, unit testing)
• Complexity of the software
• Size of the software
• Experience of the team developing the software
• Percentage of code reused from a previous stable project
• Rigor and depth of testing before product is shipped. 

Defect density is typically measured in number of defects per thousand lines of code (defects/KLOC).

Reliability Parameters
MTBF

Mean Time Between Failures (MTBF), as the name suggests, is the average time between failure of hardware modules. It is the average time a manufacturer estimates before a failure occurs in a hardware module.

MTBF for hardware modules can be obtained from the vendor for off-the-shelf hardware modules. MTBF for inhouse developed hardware modules is calculated by the hardware team developing the board.

MTBF for software can be determined by simply multiplying the defect rate with KLOCs executed per second. 

FITS

FITS is a more intuitive way of representing MTBF. FITS is nothing but the total number of failures of the module in a billion hours (i.e. 1000,000,000 hours). 

MTTR

Mean Time To Repair (MTTR), is the time taken to repair a failed hardware module. In an operational system, repair generally means replacing the hardware module. Thus hardware MTTR could be viewed as mean time to replace a failed hardware module. It should be a goal of system designers to allow for a high MTTR value and still achieve the system reliability goals. You can see from the table below that a low MTTR requirement means high operational cost for the system.

Estimating the Hardware MTTR
Where are hardware spares kept?	How is site manned?	Estimated MTTR
Onsite	24 hours a day	30 minutes
Onsite	Operator is on call 24 hours a day	2 hours
Onsite	Regular working hours on week days as well as weekends and holidays	14 hours
Onsite	Regular working hours on week days only	3 days
Offsite. Shipped by courier when fault condition is encountered.	Operator paged by system when a fault is detected.	1 week
Offsite. Maintained in an operator controlled warehouse	System is remotely located. Operator needs to be flown in to replace the hardware.	2 week

MTTR for a software module can be computed as the time taken to reboot after a software fault is detected. Thus software MTTR could be viewed as the mean time to reboot after a software fault has been detected. The goal of system designers should be to keep the software MTTR as low as possible. MTTR for software depends on several factors:

• Software fault tolerance techniques used
• OS selected (does the OS allow independent application reboot?)
• Code image downloading techniques

 More

Availability

Availability of the module is the percentage of time when system is operational. Availability of a hardware/software module can be obtained by the formula given below.

Availability is typically specified in nines notation. For example 3-nines availability corresponds to 99.9% availability. A 5-nines availability corresponds to 99.999% availability.

Downtime

Downtime per year is a more intuitive way of understanding the availability. The table below compares the availability and the corresponding downtime.

Availability	Downtime
90% (1-nine)	36.5 days/year
99% (2-nines)	3.65 days/year
99.9% (3-nines)	8.76 hours/year
99.99% (4-nines)	52 minutes/year
99.999% (5-nines)	5 minutes/year
99.9999% (6-nines)	31 seconds/year !

Disponibilidad de un sistema

Calculating Availability of Individual Components

System Availability

System Availability is calculated by modeling the system as an interconnection of parts in series and parallel. The following rules are used to decide if components should be placed in series or parallel:

• If failure of a part leads to the combination becoming inoperable, the two parts are considered to be operating in series
• If failure of a part leads to the other part taking over the operations of the failed part, the two parts are considered to be operating in parallel.

Third step involves computing the availability of individual components. MTBF (Mean time between failure) and MTTR (Mean time to repair) values are estimated for each component (See Reliability and Availability basics article for details). For hardware components, MTBF  information can be obtained from hardware manufactures data sheets. If the hardware has been developed in house, the hardware group would provide MTBF information for the board. MTTR estimates for hardware are based on the degree to which the system will be monitored by operators. Here we estimate the hardware MTTR to be around 2 hours. 

Once MTBF and MTTR are known, the availability of the component can be calculated using the following formula:

Estimating software MTBF is a tricky task. Software MTBF is really the time between subsequent reboots of the software. This interval may be estimated from the defect rate of the system. The estimate can also be based on previous experience with similar systems. Here we estimate the MTBF to be around 4000 hours. The MTTR is the time taken to reboot the failed processor. Our processor supports automatic reboot, so we estimate the software MTTR to be around 5 minute. Note that 5 minutes might seem to be on the higher side. But MTTR should include the following:

• Time wasted in activities aborted due to signal processor software crash
• Time taken to detect signal processor failure
• Time taken by the failed processor to reboot and come back in service

Component	MTBF	MTTR	Availability	Downtime
Input Transducer	100,000 hours	2 hours	99.998%	10.51 minutes/year
Signal Processor Hardware	10,000 hours	2 hours	99.98%	1.75 hours/year
Signal Processor Software	2190 hours	5 minute	99.9962%	20 minutes/year
Output Transducer	100,000 hours	2 hours	99.998%	10.51 minutes/year

Things to note from the above table are:

• Availability of software is higher, even though hardware MTBF is higher. The main reason is that software has a much lower MTTR. In other words, the software does fail often but it recovers quickly, thereby having less impact on system availability.
• The input and output transducers have fairly high availability, thus fairly high availability can be achieved even without redundant components.

Calculating System Availability

The last step involves computing the availability of the entire system. These calculations have been based on serial and parallel availability calculation formulas.

Component	Availability	Downtime
Signal Processing Complex (software + hardware)	99.9762%	2.08 hours/year
Combined availability of Signal Processing Complex 0 and 1 operating in parallel	99.99999%	3.15 seconds/year
Complete System	99.9960%	21.08 minutes/year

Almacenamiento, Protección y Respaldo de Datos

Fuente 

Un archivo informático o fichero es un conjunto de bits almacenado en un dispositivo periférico.

Un archivo es identificado por un nombre y la descripción de la carpeta o directorio que lo contiene. Los archivos informáticos se llaman así porque son los equivalentes digitales de los archivos en tarjetas, papel o microfichas del entorno de oficina tradicional. Los archivos informáticos facilitan una manera de organizar los recursos usados para almacenar permanentemente datos en un sistema informático.

Contenido de los archivos

En lo que concierne al sistema operativo, un archivo es, en la mayoría de los casos, simplemente un flujo unidimensional de bits , que es tratado por el sistema operativo como una única unidad lógica. Un archivo de datos informático normalmente tiene un tamaño, que generalmente se expresa en bytes; en todos los sistemas operativos modernos, el tamaño puede ser cualquier número entero no negativo de bytes hasta un máximo dependiente del sistema. Depende del software que se ejecuta en la computadora el interpretar esta estructura básica como por ejemplo un programa, un texto o una imagen, basándose en su nombre y contenido.

Los datos de un archivo informático normalmente consiste de paquetes más pequeños de datos (a menudo llamados registros o líneas) que son individualmente diferentes pero que comparten algún rasgo en común. Por ejemplo, un archivo de nóminas puede contener datos sobre todos los empleados de una empresa y los detalles de su nómina; cada registro del archivo de nóminas se refiere únicamente a un empleado, y todos los registros tienen la característica común de estar relacionados con las nóminas-esto es muy similar a colocar todos los datos sobre nóminas en un archivador concreto en una oficina que no tenga ninguna computadora. Un archivo de texto puede contener líneas de texto, correspondientes a líneas impresas en una hoja de papel.

La manera en que se agrupan los datos en un archivo depende completamente del tipo de archivo, adecuado a la aplicación que permite generarlo, cambiarlo y leerlo. Esto ha conducido a una plétora de estructuras de archivo más o menos estandarizadas para todos los propósitos imaginables, desde los más simples a los más complejos. La mayoría de los archivos informáticos son usados por programas o aplicaciones. Estos programas crean, modifican y borran archivos para su propio uso bajo demanda. Los programadores que crean los programas deciden qué archivos necesitan, cómo se van a usar, y (a menudo) sus nombres.

En algunos casos, los programas de computadora manipulan los archivos que se hacen visibles al usuario de la computadora. Por ejemplo, en un programa de procesamiento de texto, el usuario manipula archivos-documento a los que él mismo da nombre. El contenido del archivo-documento está organizado de una manera que el programa de procesamiento de texto entiende, pero el usuario elige el nombre y la ubicación del archivo, y proporciona la información (como palabras y texto) que se almacenará en el archivo.

Muchas aplicaciones empaquetan todos sus archivos de datos en un único archivo, usando marcadores internos para discernir los diferentes tipo de información que contienen.

Los archivos de una computadora se pueden crear, mover, modificar, aumentar, reducir y borrar. En la mayoría de los casos, los programas de computadora que se ejecutan en la computadora se encargan de estas operaciones, pero el usuario también puede manipular los archivos si es necesario. Por ejemplo, los archivos de Microsoft Office Word son normalmente creados y modificados por el programa Microsoft Word en respuesta a las órdenes del usuario, pero el usuario también puede mover, renombrar o borrar estos archivos directamente usando un programa gestor de archivos como Windows Explorer (en computadoras con sistema operativo Windows).

Protección de archivos

Muchos sistemas informáticos modernos proporcionan métodos para proteger los archivos frente a daños accidentales o intencionados. Las computadoras que permiten varios usuarios implementan permisos sobre archivos para controlar quién puede o no modificar, borrar o crear archivos y carpetas. A un usuario dado se le puede conceder solamente permiso para modificar un archivo o carpeta, pero no para borrarlo; o a un usuario se le puede conceder permiso para crear archivos o carpetas, pero no para borrarlos. Los permisos también se pueden usar para permitir que solamente ciertos usuarios vean el contenido de un archivo o carpeta. Los permisos protegen de la manipulación no autorizada o destrucción de la información de los archivos, y mantienen la información privada confidencial impidiendo que los usuarios no autorizados vean ciertos archivos.

Otro mecanismo de protección implementado en muchas computadoras es una marca de sólo lectura. Cuando esta marca está activada en un archivo (lo que puede ser realizado por un programa de computadora o por un usuario humano), el archivo puede ser examinado, pero no puede ser modificado. Esta marca es útil para información crítica que no debe ser modificada o borrada, como archivos especiales que son usados solamente por partes internas del sistema informático. Algunos sistemas incluyen también una marca oculta para hacer que ciertos archivos sean invisibles; esta marca la usa el sistema informático para ocultar archivos de sistema esenciales que los usuarios nunca deben modificar.
Protección legal de datos de archivos

La protección de datos personales y velar por la privacidad de la información es un tema de suma importancia a nivel de empresas y de países. El mal uso de información personal puede constituir un delito.

Algunos países han creado organismos que se encargan del tema y de legislar respecto del acceso, uso y confidencialidad de los datos.
Almacenamiento de archivos

En términos físicos, la mayoría de los archivos informáticos se almacenan en discos rígidos -discos magnéticos que pueden registrar datos y por lo tanto, información a lo largo de su vida útil . 

Los discos rígidos permiten acceso en menor tiempo a los archivos informáticos, al contrario de las cintas magnéticas, discos compactos grabables, unidades Zip que se usaban para realizar copias de seguridad.

En la actualidad se está generalizando el uso de discos de estado sólido en nettops y  y otros tipos de dispositivos con mucha capacidad de almacenamiento que tienen la ventaja de ser pequeños y portátiles como memorias flash.
Respaldo de archivos

Cuando los archivos informáticos contienen información que es extremadamente importante, se usa un proceso de respaldo (backup) para protegerse de desastres que podrían destruir los archivos. Hacer copias de respaldo de archivos significa simplemente hacer copias de los archivos en una ubicación separada de modo que se puedan restaurar si le pasara algo a la computadora, o si fueran borrados accidentalmente.

Hay muchas maneras de hacer copias de respaldo de archivos. La mayoría de los sistemas informáticos proporcionan utilidades para ayudar en el proceso de respaldo, que puede llegar a consumir mucho tiempo si hay muchos archivos a salvaguardar. Copiar los archivos a otro disco rígido en la misma computadora protege contra el fallo de un disco, pero si es necesario protegerse contra el fallo o destrucción de la computadora entera, entonces de deben hacer copias de los archivos en otro medio que puede sacarse de la computadora y almacenarse en una ubicación distante y segura.

El DATO

El Dato es una representación simbólica (numérica, alfabética, algorítmica etc.), un atributo o una característica de una entidad. El dato no tiene valor semántico (sentido) en sí mismo, pero si recibe un tratamiento (procesamiento) apropiado, se puede utilizar en la realización de cálculos o toma de decisiones. Es de empleo muy común en el ámbito informático y, en general, prácticamente en cualquier disciplina científica.

En programación, un dato es la expresión general que describe las características de las entidades sobre las cuales opera un algoritmo.

En Estructura de datos, es la parte minima de la información.

Un dato por sí mismo no constituye información, es el procesado de los datos lo que nos proporciona información.Véase también: Archivo informático

Calidad de Sistemas y Datos

Data quality 

Data are of high quality "if they are fit for their intended uses in operations, decision making and planning" (J. M. Juran). Alternatively, the data are deemed of high quality if they correctly represent the real-world construct to which they refer. Furthermore, apart from these definitions, as data volume increases, the question of internal consistency within data becomes paramount, regardless of fitness for use for any external purpose, e.g. a person's age and birth date may conflict within different parts of a database. The first views can often be in disagreement, even about the same set of data used for the same purpose. This article discusses the concept as it related to business data processing, although of course other data have various quality issues as well.

Contents

• 1 Definitions
• 2 History
• 3 Overview
• 4 See also
• 5 References

List of system quality attributes

• accessibility
• accountability
• accuracy
• adaptability
• administrability
• affordability
• auditability
• availability
• credibility
• debugability
• standards compliance
• process capabilities
• compatibility
• composability
• configurability
• Correctness
• customizability
• determinability
• degradability
• demonstrability
• dependability
• deployability
• distributability
• durability
• effectiveness
• efficiency
• evolvability
• extensibility
• fidelity
• flexibility
• installability
• Integrity
• interchangeability
• interoperability
• learnability
• maintainability
• manageability
• mobility
• modifiability

• modularity
• nomadicity
• operability
• orthogonality
• portability
• precision
• predictability
• recoverability
• relevance
• reliability
• repeatability
• reproducibility
• responsiveness
• reusability
• robustness
• safety
• scalability
• seamlessness
• serviceability (a.k.a. supportability)
• securability
• simplicity
• stability
• survivability
• sustainability
• tailorability
• testability
• timeliness
• traceability
• ubiquity
• understandability
• upgradability
• usability
•  
•  
•  
•  
•  
•  
•  

Integridad del mensaje

Por integridad del mensaje en computación se entiende que cuando se envíe un mensaje de una persona a otra o bien de una máquina a otra, este mensaje no sea modificado, sin que el destinatario pueda comprobarlo. La modificación se refiere tanto a una modificación explícita por alguien como a una modificación debido a un error (por ejemplo de transmisión).

En otras palabras se puede mantener la "Integridad del Mensaje" evitando que este pueda ser modificado por un tercero.

Típicamente esto se pude lograr utilizando funciones de sentido único o también llamadas funciones Hash, a las cuales se les da como dato de entrada el mensaje y devuelve un código Hash que en teoría es único para el mensaje enviado, de modo que la persona que envía el mensaje lo hace con su código Hash respectivo, la persona que los recibe utiliza la misma función Hash para comparar el código así obtenido con el código que recibe.

Existen varias implementaciones de estas funciones Hash; las más utilizadas son SHA1 y MD5 por ser de ejecución rápida, pero tienen mayor posibilidad de colisiones entre códigos generados para distintos mensajes que otras funciones que usan más bits para crear el hash de los mensajes.

Los códigos Hash de un CD de 650 Mb puede reducirse a unos cuantos Kbytes.

En combinación con llaves asimétricas es posible mantener la "Integridad del mensaje" y determinar su proveniencia.