WIXLIB

objeto. Esto garantiza que los datos privados esténprotegidos. Sin embargo, la encapsulación dificulta laaplicación de las directivas de seguridad adecuadas aun objeto porque es difícil determinar lo que contieneel objeto.cohesiónCohesión es un término utilizado para describircuántas tareas diferentes puede llevar a cabo unmódulo. Si se limita a un número pequeño o a unasola función, se dice que tiene una alta cohesión. Laalta cohesión es buena en el sentido de que se puedenhacer cambios en el modelo sin afectar a otrosmódulos. También facilita la reutilización del módulo.La mayor cohesión se proporciona limitando elalcance del funcionamiento de un módulo.acoplamientoEl acoplamiento describe cuánta interacción requiereun módulo desde otro módulo para hacer su trabajo.El acoplamiento bajo o suelto indica que un módulono necesita mucha ayuda de otros módulos, mientrasque el acoplamiento alto indica lo contrario. Si elmódulo A necesita esperar los resultados de losmensajes que envió a otros tres módulos antes de quepueda proceder, se dice que tiene un acoplamientoalto. Para resumir estas dos últimas secciones, lamejor programación proporciona una alta cohesión yun acoplamiento bajo.Estructuras de datosLa estructura de datos hace referencia a la relaciónlógica entre los elementos de datos. Describe hastaqué punto se asocian elementos, métodos de acceso yalternativas de procesamiento y la organización deelementos de datos. Estas relaciones pueden sersimples o complejas. Desde un punto de vista deseguridad, estas relaciones o la forma en que secomunican varios componentes de software y losformatos de datos que utilizan deben entenderse bien

para comprender las vulnerabilidades que podríanestar expuestas por estas estructuras de datos.Sistemas distribuidos orientados a objetosCuando una aplicación funciona en un marcocliente/servidor, como muchos lo hacen, la soluciónestá realizando la informática distribuida. Estosignifica que los componentes de diferentes sistemasdeben ser capaces de localizarse entre sí ycomunicarse en una red. Normalmente, la mayorparte de la solución está en el servidor y una piezamás pequeña se encuentra en el cliente. Esto requiereque alguna arquitectura admita esta comunicaciónproceso a proceso. Se pueden utilizar varios sistemasorientados a objetos distribuidos, como se describe enlas secciones siguientes.CORBACommon Object Request Broker Architecture(CORBA) es un estándar abierto orientado a objetosdesarrollado por el Grupo de Gestión de Objetos(OMG). Este estándar utiliza un componentedenominado Object Request Broker (ORB) paraimplementar intercambios entre objetos en unentorno heterogéneo y distribuido.La ORB gestiona toda la comunicación entrecomponentes. Acepta solicitudes de servicio de laaplicación cliente, dirige la solicitud al servidor y, acontinuación, retransmite la respuesta a la aplicacióncliente. La ORB hace posible la comunicación deforma local o remota. Esto es incluso posible entre loscomponentes que se escriben en diferentes idiomasporque utilizan una interfaz estándar paracomunicarse con la ORB.La ORB es responsable de hacer cumplir la directivade seguridad, que describe lo que los usuarios y elsistema pueden hacer y qué acciones estánrestringidas. Proporciona cuatro tipos de directivas:

control de acceso, protección de datos, no repetición yauditoría.COM y DCOMEl modelo de objetos componentes (COM) es unmodelo de comunicación entre procesos en el mismoequipo, mientras que, como su nombre indica, elmodelo de objetos de componente distribuido(DCOM) es un modelo de comunicación entreprocesos en diferentes partes de la red. DCOMfunciona como middleware entre estos procesosremotos (denominado comunicación entre procesos[IPC]).DCOM presta los mismos servicios que losproporcionados por el ORB en el marco corba; esdecir, conectividad de datos, servicio de mensajes yservicio de transacciones distribuidas. Todas estasfunciones están integradas en una tecnología queutiliza la misma interfaz que COM.OleLa vinculación e incrustación de objetos (OLE) es unmétodo para compartir objetos en un equipo local queusa COM como base. De hecho, OLE a veces sedescribe como el predecesor de COM. Permiteincrustar objetos en documentos (hojas de cálculo,gráficos, etc.). El término vinculación se refiere a larelación entre un programa y otro, y el términoincrustación se refiere a la colocación de datos en unprograma o documento extranjero.JavaJava Platform, Enterprise Edition (Java EE) isanother distributed component model that relies onthe Java programming language. It is a frameworkused to develop software that provides APIs fornetworking services and uses an interprocesscommunication process that is based on CORBA. Itsgoal is to provide a standardized method of providing

back-end code that carries out business logic forenterprise applications.SOAA newer approach to providing a distributedcomputing model is the service-oriented architecture(SOA). It operates on the theory of providing webbased communication functionality without eachapplication requiring redundant code to be writtenper application. It uses standardized interfaces andcomponents called service brokers to facilitatecommunication among web-based applications.Mobile CodeMobile code is a type of code that can be transferredacross a network and then executed on a remotesystem or device. The security concerns with mobilecode revolve around the prevention of the executionof malicious code without the knowledge of the user.This section covers the two main types of mobile code,Java applets and ActiveX applets, and the way theyoperate.Java AppletsA Java applet is a small component created usingJava that runs in a web browser. It is platformindependent and creates intermediate code calledbyte code that is not processor-specific. When theapplet downloads to the computer, the Java virtualmachine (JVM), which must be present on thedestination computer, converts the byte code tomachine code.The JVM executes the applet in a protectedenvironment called a sandbox. This critical securityfeature, called the Java Security Model (JSM), helpsto mitigate the extent of damage that could be causedby malicious code. However, it does not eliminate theproblem with hostile applets (also called activecontent modules), so Java applets should still be

regarded with suspicion because they might launch anintentional attack after being downloaded from theInternet.ActiveXActiveX is a Microsoft technology that uses OOP andis based on the COM and DCOM. These self-sufficientprograms, called controls, become a part of theoperating system after they’re downloaded. Theproblem is that these controls execute under thesecurity context of the current user, which in manycases has administrator rights. This means that amalicious ActiveX control could do some seriousdamage.ActiveX uses Authenticode technology to digitally signthe controls. This system has been shown to havesignificant flaws, and ActiveX controls are generallyregarded with more suspicion than Java applets.NIST SP 800-163NIST SP 800-163, “Vetting the Security of MobileApplications,” was written to help organizations (1)understand the process for vetting the security ofmobile applications, (2) plan for the implementationof an app vetting process, (3) develop app securityrequirements, (4) understand the types of appvulnerabilities and the testing methods used to detectthose vulnerabilities, and (5) determine if an app isacceptable for deployment on the organization’smobile devices.To provide software assurance for apps, organizationsshould develop security requirements that specify, forexample, how data used by an app should be secured,the environment in which an app will be deployed,and the acceptable level of risk for an app. To helpensure that an app conforms to such requirements, aprocess for evaluating the security of apps should beperformed. This process is referred to as an appvetting process. An app vetting process is a sequence

of activities that aims to determine if an app conformsto the organization’s security requirements. Thisprocess is performed on an app after the app has beendeveloped and released for distribution but prior to itsdeployment on an organization’s mobile device. Thus,an app vetting process is distinguished from softwareassurance processes that may occur during thesoftware development life cycle of an app. Note thatan app vetting process typically involves analysis of anapp’s compiled, binary representation but can alsoinvolve analysis of the app’s source code if it isavailable.An app vetting process comprises a sequence of twomain activities: app testing and appapproval/rejection.According to NIST SP 800-163, an app vettingprocess begins when an app is submitted by a mobiledevice administrator to one or more analyzers fortesting. Apps that are submitted by an administratorfor testing will typically be acquired from an app storeor an app developer, each of which may be internal orexternal to the organization. An analyzer is a service,tool, or human that tests an app for specific softwarevulnerabilities and may be internal or external to theorganization. After an app has been received andpreprocessed by an analyzer, the analyzer then teststhe app for the presence of software vulnerabilities.Such testing may include a wide variety of testsincluding static and dynamic analyses and may beperformed in an automated or manual fashion. Notethat the tests performed by an analyzer are notorganization-specific but instead are aimed atidentifying software vulnerabilities that may becommon across different apps. After testing an app,an analyzer generates a report that identifies detectedsoftware vulnerabilities. In addition, the analyzergenerates a risk assessment that estimates thelikelihood that a detected vulnerability will beexploited and the impact that the detected

vulnerability may have on the app or its related deviceor network. Risk assessments are typicallyrepresented as ordinal values indicating the severityof the risk (for example, low-, moderate-, and highrisk).After the report and risk assessment are generated byan analyzer, they are made available to one or moreauditors of the organization. The auditor inspectsreports and risk assessments from one or moreanalyzers to ensure that an app meets the securityrequirements of the organization. The auditor alsoevaluates additional criteria to determine if the appviolates any organization-specific securityrequirements that could not be ascertained by theanalyzers. After evaluating all reports, riskassessments, and additional criteria, the auditor thencollates this information into a single report and riskassessment and derives a recommendation forapproving or rejecting the app based on the overallsecurity posture of the app. This recommendation isthen made available to an approver. An approver usesthe recommendations provided by one or moreauditors that describe the security posture of the appas well as other non-security-related criteria todetermine the organization’s official approval orrejection of an app. If an app is approved by theapprover, the administrator is then permitted todeploy the app on the organization’s mobile devices.If, however, the app is rejected, the organization willfollow specified procedures for identifying a suitablealternative app or rectifying issues with theproblematic app.According to NIST SP 800-163, before anorganization can implement an app vetting process, itis necessary for the organization to first (1) developapp security requirements, (2) understand thelimitations of app vetting, and (3) procure a budgetand staff for supporting the app vetting process.

A general requirement is an app security requirementthat specifies a software characteristic or behaviorthat an app should exhibit in order to be consideredsecure. General app security requirements includeEnabling authorized functionality: The appmust work as described; all buttons, menu items,and other interfaces must work. Error conditionsmust be handled gracefully, such as when a serviceor function is unavailable (for example, disabled,unreachable, and so on).Preventing unauthorized functionality:Unauthorized functionality, such as dataexfiltration performed by malware, must not besupported.Limiting permissions: Apps should have onlythe minimum permissions necessary and shouldonly grant other applications the necessarypermissions.Protección de datos confidenciales: Lasaplicaciones que recopilan, almacenan ytransmiten datos confidenciales deben proteger laconfidencialidad e integridad de estos datos. Estacategoría incluye preservar la privacidad, comopedir permiso para usar información personal yusarla solo con fines autorizados.Protección de dependencias de código deaplicación: La aplicación debe usar cualquierdependencia, como en bibliotecas, de una manerarazonable y no por razones maliciosas.Pruebas de actualizaciones de aplicaciones:Las nuevas versiones de la aplicación debenprobarse para identificar cualquier nuevadebilidad.Un requisito contextual es un requisito de seguridadde la aplicación que especifica cómo la organización

debe usar las aplicaciones para garantizar la posturade seguridad de esa organización. Para unaaplicación, los analizadores no pueden determinar lasatisfacción o la violación de los requisitoscontextuales, sino que deben ser determinados por unauditor mediante criterios de investigación específicosde la organización. Estos criterios incluyenRequisitos: Los requisitos pertinentes, laspolíticas de seguridad, las políticas de privacidad,las políticas de uso aceptables y las directrices deredes sociales que son aplicables a la organización.Procedencia: Identidad del desarrollador,organización del desarrollador, reputación deldesarrollador, fecha recibida, revisiones deconsumidores de marketplace/app store, etc.Sensibilidad de datos: La sensibilidad relativade los datos recopilados, almacenados y/otransmitidos por la aplicación.Criticidad de la aplicación: Qué tan crítica esla aplicación para los procesos empresariales de laorganización.Usuarios de destino: El conjunto previsto deusuarios de la aplicación.Hardware de destino: La plataforma dehardware prevista y la configuración en la que seimplementará la aplicación.Entorno objetivo: El entorno operativo previstode la aplicación (por ejemplo, uso público generalfrente a entorno militar sensible).Firma digital: Firmas digitales aplicadas a losarchivos binarios o paquetes de la aplicación.Documentación de la aplicación:

Guía del usuario: Cuando está disponible, laguía del usuario de la aplicación ayuda a laspruebas especificando la funcionalidadesperada y los comportamientos esperados.Esto es simplemente una declaración deldesarrollador que describe lo que afirman quehace su aplicación y cómo lo hace.Planes de prueba: Revisar los planes deprueba del desarrollador puede ayudar aenfocar la investigación de aplicacionesmediante la identificación de cualquier área queno haya sido probada o que haya sido probadade manera inadecuada. Un desarrollador podríaoptar por enviar un oráculo de prueba en ciertassituaciones para demostrar su esfuerzo deprueba interno.Resultados de las pruebas: Los resultadosde la revisión de código y otros resultados de laspruebas indicarán qué normas de seguridad sesiguieron. Por ejemplo, si se creó un modelo deamenaza de aplicación, debe enviarse. Estoenumerará las debilidades que se identificarony deberían haberse abordado durante el diseñoy la codificación de la aplicación.Acuerdo de nivel de servicio: Si unaaplicación fue desarrollada para unaorganización por un tercero, es posible que sehaya incluido un acuerdo de nivel de servicio(SLA) como parte del contrato de proveedor.Este contrato debe requerir que la aplicaciónsea compatible con la directiva de seguridad dela organización.SEGURIDAD EN LOS CICLOS DE VIDADE DESARROLLO DE SISTEMAS YSOFTWAREAl escribir código para nuevo software, losdesarrolladores deben asegurarse de que se

implementan los controles de seguridad adecuados yde que el código está protegido correctamente. Estasección cubre el Ciclo de Vida de Desarrollo delSistema; el Ciclo de Vida de Desarrollo de Software;métodos de desarrollo de software y modelos demadurez; operación y mantenimiento; gestión delcambio; y el equipo de producto integrado.Ciclo de vida de desarrollo del sistemaCuando una organización define una nuevafuncionalidad que debe proporcionarse a sus clienteso internamente, debe crear sistemas para ofrecer esafuncionalidad. Hay que tomar muchas decisiones yseguir un proceso lógico para tomar esas decisiones.Este proceso se denomina ciclo de vida de desarrollodel sistema. En lugar de ser un enfoque azaroso, elSDLC proporciona pasos claros y lógicos a seguir paragarantizar que el sistema que surge al final delproceso de desarrollo proporcione la funcionalidadprevista con un nivel aceptable de seguridad.El Ciclo de vida de desarrollo del sistema incluye lassiguientes fases:1. iniciar2. Adquirir/Desarrollar3. instrumento4. Operar/Mantener5. disponerEn esta sección se explican las cinco fases del Ciclo devida de desarrollo del sistema.iniciar

En la fase Iniciar, se realiza que se desea o requiereuna nueva característica o funcionalidad en una piezade software existente. Esta nueva característica podríaconstituir una actualización de un producto existenteo el desarrollo de una pieza de softwarecompletamente nueva. En cualquier caso, la faseIniciar incluye tomar una decisión sobre si comprar odesarrollar el producto internamente.En esta etapa, una organización también debe teneren cuenta los requisitos de seguridad de la solución.La creación de una evaluación preliminar del riesgose puede utilizar para detallar los requisitos ypreocupaciones de confidencialidad, integridad ydisponibilidad (CIA). Identificar estos problemasdesde el principio es importante para que estasconsideraciones puedan guiar la compra o eldesarrollo de la solución. Cuanto antes se identifiqueel ciclo de vida de desarrollo del sistema, que seidentifican los requisitos de seguridad, más probablees que los problemas se aborden correctamente en elproducto final.Adquirir/DesarrollarEn la etapa de adquisición/desarrollo del Ciclo deVida de Desarrollo del Sistema, se llevan a cabo unaserie de actividades que proporcionan aportes parafacilitar la toma de una decisión sobre la adquisición odesarrollo de la solución; la organización entoncestoma una decisión sobre la solución. Las actividadesestán diseñadas para obtener respuestas a lassiguientes preguntas:¿Qué funciones necesita realizar el sistema?¿Cuáles son los riesgos potenciales para la CIAexpuestos por la solución?What protection levels must be provided to satisfylegal and regulatory requirements?

What tests are required to ensure that securityconcerns have been mitigated?How do various third-party solutions address theseconcerns?How do the security controls required by thesolution affect other parts of the com

Guía de certificados cissp, 3ª edición E v a l u a r l a e f i c a c i a d e l a se g u r i d a d d e l so f t w a r e :