Implementación de Sistemas de Información Seguros

Presentación del tema: "Implementación de Sistemas de Información Seguros"— Transcripción de la presentación:

1 Implementación de Sistemas de Información Seguros
Cristian Mora Aguilar, CISSP, CISM, MCSE+Security Security Consultant Microsoft Security Center of Excellence, SCoE

2 Agenda Conceptos básicos de seguridad Triada de Seguridad CIA
Seguridad en Aplicaciones: Más que un problema Tecnológico Componentes básicos para de Seguridad Arquitectura Administración de Riesgo Defensa en profundidad Seguridad en Aplicaciones Modelo de Amenazas (Threat Modeling) y STRIDE Herramientas: FXCop Caso de Estudio DJ Hell Defacement

3 Triada de Seguridad CID
Confidencialidad Integridad Disponibilidad Confidencialidad Integridad Disponibilidad

4 Seguridad de Aplicaciones: Más que un problema Tecnológico
Procesos Tecnologías Operaciones

5 Modelo de Infraestructura Tecnológico y WSSRA

6 El Problema Tecnológico
Evolving an architecture outside of a standardized, well understood framework leads to complexity, compromise, inefficiency, “you need to speak to Bob” syndrome (he’s the only one that knows something) Crecimiento informal Administración lenta y Compleja de los componentes

7 Ambiente de Infraestructura
<IF ILYA HAS AN UPDATE TO THIS THEN REPLACE>

8 Arquitectura de Referencia
The criteria ensure server products individually meet high standards of consistency and coherency – Reference architecture ensures high degrees of integration with each other and our partners software and hardware components. Provide an customer representative environment for Microsoft products to be developed and tested within. Improves MS products while also providing customers\partners with guidance on how to design and deploy actual environments. “A Standardized approach to designing and deploying an optimized Windows based platform”

9 Zonas de Seguridad Security Zones:
Complete zone definitions based on traffic type and access requirements. MSS

10 Segmentación de Redes Broke out perimeter into semi trusted and un-trusted traffic – two flows Network Zones: Network derived as a joint effort between MS and Cisco. Multi-treaded network design, e.g. multiple traffic paths – corporate clients egress thru the perimeter via a firewall (ISA) dedicated to semi-trusted (employee) traffic; public access perimeter services via a firewall (ISA) dedicated to untrusted traffic. If on path fails the other path is still available so the whole network is not down. Core switch was added to the design to aggregate wiring, this will reduce wiring costs and provide better scalability in and enterprise network. Also topographical changes like adding or moving offices in a campus network impact the L3 core switch rather than the aggregation switches which have the complex configurations, ACLs and CSM & Firewall blades. FWM (Firewall Module): A Cisco Firewall blade was used to provide internal firewall services rather than a standalone PIX device – this allowed greater flexibility and firewalling to happen at wire-speeds. CSM (Content Switch Modules): Hardware based load-balancing (Cisco switch blade) was added to the design to provide better performance, simplified configurations and better service availability. SBOs connect to the CDC via a site-to-site VPN solution consisting of a Cisco router at the SBO and a this perimeter RRAS servers in the CDC. Site-to-site is fully fault tolerant.

11 Almacenamiento MSA v2 R1 deploys a “Hybrid Storage Architecture Model” with a combination of DAS and SAN DAS utilized for Domain Controllers, Certificate, VPN, Proxy, WEB/App, WINS, Perimeter, Mgmt, Deployment services SAN utilized for File, Print, SQL, DHCP, Backup services NAS was not utilized as Windows Server 2003 powered devices were not available MSA v2 R1 deployed a dual Edge – Core – Edge SAN Fabric Design Each 8 BROCADE 3800 switch SAN fabric demonstrates availability, scalability, and price/performance ratio SAN fabric zones implemented per service and for backup & isolation LAN free backups enabled by connecting tape library to the SAN Fabric MSA v2 R1 deployed two storage array systems on ONE SAN Fabric HP Enterprise Virtual Array 5000 for File, Print, DHCP, SQL EMC Clariion CX600 for Windows Server 2003 Datacenter SQL services on Unisys ES7000 Hardware LUN masking at storage controller was used to further secure data access per individual HBA WWN All servers ran 3rd-party multi-path I/O software Differences from MSA EDC v1.5 3 tier vs. 2 tier SAN Fabric Design Single SAN Fabric for both storage arrays No Windows powered NAS devices 2 Gb vs. 1Gb fabric NOTES: Architecture MSA defines 3 Storage Architectures: Centralized (All data on a SAN and/or NAS) Distributed (Direct-Attached Storage DAS for all services) and Hybrid (combination of previous 2) - Hybrid Storage architecture provides flexibility by choosing the best storage design for each service. SAN Fabric SAN Fabric Design can be as varied as network designs, but core-edge designs provide maximum scalability and availability at price/perf ratios. Single SAN Fabric enables management from one toolset or using 3rd party tools from HP / EMC. SAN islands were not created to meet consolidation and shared infrastructure services MSA goals. Single Fabric provides centralized backup/restore. 2Gb fabric is latest technology available today from partners. SAN Devices SAN devices from industry leading partners prove that MSA is flexible and works together. Note: All SAN LUNs were sized based on Test Tool workloads and not specific any Corporate Usage Profile. Other: VSS/VDS, Microsoft Multi-Path I/O, StorPort drivers were NOT utilized in the MSA Lab implementation due to timing issues and availability of required partner

12 Componentes básicos de Servicios de Red
DNS now utilizes an internal root. This allows for easier integration of internal namespaces when acquiring companies. Standalone caching DNS servers utilized internally. Internal clients (servers still direct queries directly to the DCs) utilize the caching servers for name resolution. This allows large enterprises to scale out their DNS name services as well as take DCs up and down without affecting large number of clients. WINS HUB on cluster This is primarily for management reasons. Originally you'd have a standby WINS server, if the hub went down you'd break all the replication connections and reconfigure them to the standby server. For large enterprises this is time consuming and costly.  By using a cluster for the HUB, we don't have to do the reconfiguration. Cross forest trusts utilized from perimeter to internal AD for mgmt purposes This allows for centralized management in a secure manner.  Even if the perimeter is compromised at the domain level, provided the accounts and passwords are not the same in both forests, the attacker will still not be able to enumerate the internal forest. MSS Group Policies are leveraged. We leveraged MSS policies and overrode them with MSA policies as necessary to support our services. Internal Proxy Services We can now control access to the internet through groups in 2.0 since the internal proxies are part of the corporate domain. They then relay their external requests to a second set of proxy services upstream. Proxy services internally – effects DNS arch, did not have an internal DNS cnahged sig becoz of internal root – ease of adding Co’s Wins on cluster for H/A and mgmt. MSS group policies implemented in MSA 2.0 Cross forest trust to internal AD for mgmt purposes – centralized mgmt of both infra External proxy are standalone

13 Servicios de Aplicación
Show you how to utilize the enterprise infrastructure that has been setup using MSA 2.0 to run a variety of enterprise applications. Touches upon the issues that ITPros and Developers need to understand in order to delver the enterprise level IT applications seamlessly. The “Application Infrastructure Architecture” blueprint introduces application architecture options, including concepts and technologies such as .NET and COM component models, Microsoft Message Queuing (also known as MSMQ), and the role of Internet Information Services (IIS). We also discuss ten different design options for implementing the logical layers of an application across different physical tiers and trust zones, including architectural advantages and disadvantages of each design option. Application Servers (Middleware Services): In previous versions of MSA, IDC 1.5 and EDC 1.5, we did not have the applications servers in our architecture to run the middleware component because our scope was already too big. In MSA 2.0 we have made the provision for the Application Servers in our architecture, which can be used to run a variety of application components depending upon your requirements. For example you could run the middle ware components that use the operating system services like COM+, MSMQ and .NET Web Services. From a blueprint perspective we chose to cover .NET framework configurations and installation options like side-by-side installation of .NET Framework 1.0 and .Net Framework 1.1 (one that ships with Windows 2003) in more detail because we expect our customers to have developed applications using .NET Framework 1.0. These application servers are enabled to host middleware components developed using .NET, COM+, as well as XML Web Services. These application servers can also designed to host other middleware based Windows Server System products like BizTalk Server and Commerce Server. We used the .NET version of F&M Stocks (Fitch and Mather Stocks) sample application to verify the three tier functionality of the MSA architecture and also to verify the .NET remoting within the MSA infrastructure.

14 Servicios de Administración
Management Services: Talk about MSM here for Management of services. MSA provided guidance on building and deploying a tool and symbols server as part of the management sub-system for both the perimeter and internal networks. Separation of management services and authorization between perimeter and internal network as well as between network and server devices.

15 Servicios Públicos y Clientes
Client Access: Internal and WAN clients aggregate to a separate core switch to reduce configuration and impact to aggregation switches (switches that have the CSM and Firewall blades). SBO scenario is new. SBOs connect to the CDC via a site-to-site VPN solution consisting of a Cisco router at the SBO and a this perimeter RRAS servers in the CDC. Site-to-site is fully fault tolerant. Client and site-to-site VPN consolidation. Authenticated internal, remote and WAN clients treated as semi-trusted users and sandwiched between two firewalls.

16 Análisis de Riesgo

17 Administración de Riesgos y soporte para decisiones
Alto Riesgo NO Aceptable La administración de riesgo define un nivel aceptable del mismo Impacto al negocio El equipo de negocios define el impacto Key Message: Make it very clear that security risks can never be completely eliminated, but that what an organization can and must do is implement controls to reduce the probability of a successful exploit to an acceptable level. Explain that while there are many ways of conceptualizing and talking about risk management, you’ll be employing a few common terms in this presentation, only for the sake of making sure that we’re all on the same page right here and now in this room. Don’t let resistance to or questioning of this common terminology and framework hang up the discussion. Talking Points: “Using industry standard definitions, risk is the probability of an impact occurring against your business.” “You can’t change the impact component of risk; you can only implement security controls that reduce the probability.” “Security solutions are designed to reduce the probability of a successful exploit.” “The goal of risk reduction is to move your individual level of risk from an unacceptable level to an acceptable one. Your level of acceptable risk is unique to your business; later, we’ll talk about ways of assessing and reducing risk.” “Decision support is used to prioritize risk based on a cost/benefit analysis: the cost of the security solution to mitigate a risk is weighed against the business benefit of mitigating the risk.” “The clear assignment of roles and responsibilities is a critical part of decision support. You are deciding not only which measures to take, but also how those decisions will be made, and by whom, and who will be responsible for implementing and monitoring them.” Additional Information: Risk Assessment Typically, the corporate security group owns identification of the probability of the exploit occurring. Business owners are responsible for identifying the impact of an exploit, because business owners are in the best position to identify the business value of the assets necessary to operations. An exploit that has a high likelihood of either expanding, exposing, or escalating risk from one business asset to other business assets in the enterprise is usually considered an “unacceptable risk”. Decision Support The corporate security group also owns the decision to implement a security solution when the likelihood of an exploit places the risk assessment to the right of the curve shown on the slide, in “unacceptable risk” territory.  When the risk is not “unacceptable” to the enterprise as a whole, the business owner of the asset owns the decision to implement a security solution to mitigate the risk.  Components of Risk Assessment The risk-assessment process sets mitigation priorities based on (a) the likelihood of a successful exploit occurring and (b) the potential impact of the exploit. Risk assessment represents an important step in understanding security problems for the business and prioritizing reduction of risk within available resources. The diagram on this slide presents the basic components of the risk assessment. By communicating a consistent structure for evaluating the components of risk, digital asset owners and IT have a common taxonomy for tracking progress and contributing to the evaluation process. It is important to note that many stakeholders are required to sufficiently address each component. This is especially true for the more subjective areas of business impact costs, the likelihood of vulnerabilities occurring, and the larger cost/benefit analysis required when evaluating new control solutions. Stakeholders can include risk-management experts who are involved in calculating risk, security analysts who know specific vulnerabilities and threat probabilities, data owners who understand the value of the digital assets under consideration, and security architects and engineers who can identify potential security controls to mitigate risk. Enterprise Risk Model Risk management provides organizations with a consistent, clear method for organizing and prioritizing the limited resources available for managing risk. Benefits are realized by developing a cost-effective control environment that drives down risk to an acceptable level. The graph on this slide shows the overall risk reduction through application of the risk management framework. The optimal definition of acceptable risk, and the optimal approach to managing risk, varies for each business. There is no right or wrong answer; there are many risk management models in use today. Each model has tradeoffs that balance accuracy, resources, time, complexity, and subjectivity. The model we are offering here a combination of various approaches (such as pure quantitative analysis, return-on-security-investment analysis, qualitative analysis, and best-practice approaches). Riesgo Aceptable Ejecución de la vulnerabilidad Bajo Alto El equipo de Seguridad de información define la probabilidad

18 Amenazas de Seguridad de TI
Ambiente de Seguridad Dispositivos Clientes Servidores Físico Red Servidor Apps Datos Defensa en profundidad Amenazas Amenazas Amenazas Amenazas Amenazas Amenazas Key Message: Explain that the most effective security solutions will also be the ones that address multiple intersections on the dashboard, and that this type of efficiency very often results in an organization’s increased appreciation of the IT Security team’s work. In this way, IT security comes to be seen as being of real value, a business asset well worth the necessary resources. Talking Points: “In the slide, you can see how a combination of solutions could be implemented to reduce the risks associated with specific threats and vulnerabilities in specific environments.” “As you may notice, solutions tend to incorporate controls which apply on multiple defense layers and are relevant to multiple environments.” [Bridge to next slide:] “Once these solutions have been implemented, and are fully up and running, the risk which was originally identified should be reassessed.”

19 Análisis de Riesgo Defensa en Profundidad Ambiente de Seguridad
Físico Red Servidor Apps Datos Servidores Evaluación de riesgo en cada capa Mejor visión de la situación actual Cada sección tiene una clasificación de riesgo y un plan de mitigación Clientes Key Message: Explain that when they evaluate their target environments, they must identify both where the opportunities and where the needs exist for improving their organization’s security posture. Remind them that what makes it possible to make these identifications in a clear and specific way is the clarity and specificity of the dashboard itself, with its distinct intersections of each target environment with each defense layer. Talking Points: “Begin by assessing the level of risk at each intersection between one target environment and one defense layer.” “Now, create two security grids, using common threats and vulnerabilities to guide your assessment: In the first grid, supply the status of your organization’s IT security vulnerabilities as they currently exist. In the second grid, identify the status of those vulnerabilities as they should be after you have implemented an improved security policy. The differences between the two grids identifies your organization’s IT security “gap”―those areas where improved security solutions are needed.” “Once you have identified the gap, you can identify the improved solutions that will best effect the transition between the “As Is” grid and the “Should Be” grid. One tool that can be very useful in this process is the Microsoft Security Solutions Blueprint, which we’ll be talking about a little later on.” “Finally―if necessary―evaluate the cost effectiveness of the various security solutions required to mitigate the various identified risks: In order to evaluate cost effectiveness, you must first identify the value of the protected asset to the business. When you have identified the value of the protected asset (or of the materiality of the loss of the asset), the cost of the needed security control can be compared to the value (or materiality of loss) of the asset. Here’s an example of this process: In a fictional financial services company, there is a database. In this database is contained all of the account information that the company uses to calculate interest and generate its profits. Without this database, the company could not function. What is the value of this IT asset? The answer: The value is relative to the total revenues of the company. That is, the greater the revenues the company generates, the greater the resources that should be made available to implement IT security controls to protect the confidentiality, integrity, and availability of their database.” Aceptable Dispositivos Control en Progreso No Aceptable

20 Resultado de Análisis de Riesgo
Defensa en Profundidad Ambiente de Seguridad Físico Red Servidor Apps Datos Servidores Clientes Key Message: Explain that when creating the As Is grid, no organization should come up with a completely green security dashboard. Also explain that an organization should not consider red indicators as IT security failures, but rather as useful identifiers of areas where improvements should be considered. Talking Points: “Assuming that we are working in an organization that has three environments, and evaluating the vulnerabilities of each of those environments at each of the defense layers we’ve identified, here is an example of the possible results of analyzing the security posture at each intersection.” “Every organization should have the ability to create a similar view of their environments intersected by their defense layers.” Dispositivos

21 Implementación de Soluciones
Defensa en Profundidad Ambiente de Seguridad Físico Red servidor Apps Datos Servidores Solución Solución Clientes Solución Solución Solución Solución Key Message: Explain that the most effective security solutions will also be the ones that address multiple intersections on the dashboard, and that this type of efficiency very often results in an organization’s increased appreciation of the IT Security team’s work. In this way, IT security comes to be seen as being of real value, a business asset well worth the necessary resources. Talking Points: “In the slide, you can see how a combination of solutions could be implemented to reduce the risks associated with specific threats and vulnerabilities in specific environments.” “As you may notice, solutions tend to incorporate controls which apply on multiple defense layers and are relevant to multiple environments.” [Bridge to next slide:] “Once these solutions have been implemented, and are fully up and running, the risk which was originally identified should be reassessed.” Dispositivos

22 Plan de Evaluación de Resultados
Defensa en Profundidad Ambiente de Seguridad Física Red Servidor Apps Datos Servidores Clientes Key Message: Explain that after the organization has implemented the chosen solutions, the As Is dashboard should be changed to indicate where the associated risks have been managed to an acceptable level. Talking Points: “Having initially identified our security posture at the intersection of each environment and layer; and, if needed, evaluated the cost effectiveness of available security solutions to mitigate the identified risks.” “Next, we implemented solutions to reduce our risk of impact”. “Now, we have re-evaluated our security posture at each of those same intersections.” “The result is an updated dashboard, identifying those areas that we need to stay aware of.” “This step: Completes the strategic security process. Provides qualitative and quantitative feedback on security improvements. Becomes input into next iteration of risk assessment.” Dispositivos

23 Defensa en Profundidad

24 Defensa en Profundidad
Medidas de control segmentadas en capas de protección Aplica medidas de control en cada capa de cada componente que interactúa en una solución, desde la capa de perímetro hasta la capa de datos Reduce la posibilidad de un único punto de vulnerabilidades cuando el sistema es atacado Reducción del riesgo por: Análisis de vulnerabilidades presentes en los sistemas Análisis de amenazas presentes que pueden tomar ventaja de esas vulnerabilidades Implementación de los medidas de control apropiadas en cada capa

25 Defensa en Profundidad
Políticas, procedimientos, Concientización Seguridad Física Perímetro Red Servidor Aplicación Datos

26 Como minimizar la superficie de ataque?
Políticas, Procedimientos, Concientización Seguridad Física Listas de Acceso, Encriptación, EFS Datos Aseguramiento de App, Antivirus Aplicación Aseguramiento del SO, Autenticación, Actualizaciones de OS, Detector de Intrusos local Servidor Red Interna Segmentación de Red, IPSec, Detector de Intrusos dered Perímetro Muros de fuego, Control de acceso de Cuarentena Guardas, Cerrojos, Dispositivos de monitoreo Documentación de Seguridad, Educación al Usuario

27 Seguridad en aplicaciones

28 Amenazas de Seguridad más comunes

29 Vulnerabilidades por Años
Data Source: Secunia (

30 Seguridad en la arquitectura
Seguridad en el modelo de desarrollo Estrategia SD3 Seguridad en el diseño por capas Holística de la seguridad

31 Seguridad en el modelo de desarrollo
Analizar amenazas Aprender y refinar Revisión externa Preguntas durante las entrevistas Determinar los criterios de validación de la seguridad “Security push” Concepto Entrega Después de la entrega Diseños completados Planes de pruebas completados Código completado Entrenar a los miembros del equipo Revisar defectos anteriores, comprobar registros directrices de programación segura, usar herramientas Revisión del equipo de seguridad Pruebas de mutación de datos y mínimos privilegios =continuo

32 Modelo de análisis de Riesgos
Entender las amenazas hacia las aplicaciones/sistema Uso de modelo de riesgo para identificar riesgos Diferente a la fase de pruebas y servicios Consideraciones de diseño de alto nivel Permite una mitigación proactiva de la mitigación de amenazas Secure apps cannot be created without understanding all threats to your app/system

33 Proceso para el Modelo de analisis de riesgo
Crear un modelo de la aplicación (UML, DFD, etc.) Utilizar STRIDE para categorizar los tipos de amenazas Para cada destino de ataque Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation of privilege Construcción de un arbol de amenazas Categorizar las amenazas con DREAD Damage potential, Reproducibility, Exploitability, Affected users, Discoverability UML Unified Modeling Language DFD Data Flow Diagram Inventories the components of app, or a list of things that can be attacked Threat tree list things that need to happen for threat to be realized

34 Árbol de Amenazas

35 Para cada proceso en el Modelo
Es el proceso susceptible a spoofing? Puede ser el proceso alterado? Existe la posibilidad de manejar no repudio en la aplicación? Pueden un ataque resultar en la vista no autorizada de los datos? Puede un ataque de DoS deshabilitar el proceso? Puede ser ejecutado la elevación de privilegios si un proceso ha sido atacado?

36 Aplicando STRIDE S a T R I D E Procesos Afectados
Afecta datos almacenados Afecta en interacción Afecta el flujo de datos S a T R I D E

37 Mitigación de Amenazas
Técnicas de Mitigación S Autenticación, Almacenamiento de credenciales seguras T Autorización, firmas digitales R Autenticación, autorización, firmas digitales, bitácoras I Autorización, Encriptación D Filtrado, Autenticación, Autorización E No utilizar identidades las cuales tienen altos niveles de privilegios

38 Priorización de Amenazas
Utilización del modelo de análisis de riesgo (DREAD) para asignar las prioridades a las áreas mas criticas basado en sus amenazas Priorizar mitigaciones de seguridad Priorizar revisiones periódicas Estrategias de reutilización

39 Pruebas de los planes de mitigación a amenazas
Necesidad plan de prueba para cada amenaza Pruebas básicas de acceso y funcionalidad Pruebas intrusivas El modelo de amenazas dirige el plan de pruebas Proceso de fin a fin

40 Probando el plan de mitigación de amenazas
Spoofing Autenticación Intento de cracking, replay, ver datos “en la red física” Almacenamiento seguro de las credenciales Intentar compromiso de acceso a información Tampering Intentar ingresar sin autenticacion Intentar de invalidar/modificar “hashes” firmas

41 Probando el plan de mitigación de amenazas
Repudiation Intentar de eludir la autenticación/autorización Intentar Evitar firmas Intento de evitar bitácoras, o bien escribir bitácoras falsas Information Disclosure Intento de acceso a información no autorizada Intentar de ver el dato en la red (eavesdropping) Eliminar un proceso, mirar datos sensitivos Intento de causar errores de condición, mirar las bitácoras

42 Pruebas de mitigación de amenaza
Denial of Service Filtrado Envío de datos mal formados Consumo de recursos Elevation of Privilege No poseer acceso a procesos ejecutándose con altos privilegios

43 Desarrollo de objetivos de seguridad
Elevar el nivel de seguridad de la aplicación Identificar cuando y como se requiere autenticación o autorización Identificar donde y como usted necesita para asegurar la comunicación de ambos para su aplicación (desde usuarios finales) y entre aplicaciones de terceros Identificar dificultadas comunes y como evitarlas Identificar riesgos principales y su mitigación relacionada a la autenticación y a la autorización Evitar minimizar la seguridad de hacer cosas para trabajar Identificar no solamente como y donde, pero también cuando usar varias características de seguridad Eliminar el miedo, duda e incertidumbre Promover mejores practicas y obtener resultados predecibles

44 Desarrollo de Principios básicos de Seguridad
Adoptar el principio del mínimo privilegio Utilizar defensa en profundidad No confiar en el ingreso de datos de los usuarios Utilice siempre la seguridad como base de todo proceso de configuración inicial No confiar en la seguridad por oscuridad Reducir la superficie de ataque SI existe una falla que se redirija a un modo seguro Adopt the principle of least privilege. Processes that run script or execute code should run under a least privileged account to limit the potential damage that can be done if the process is compromised. If a malicious user manages to inject code into a server process, the privileges granted to that process determine to a large degree the types of operations the user is able to perform. Code that requires additional trust (and raised privileges) should be isolated within separate processes. The ASP.NET team made a conscious decision to run the ASP.NET account with least privileges (using the ASPNET account). During the beta release of the .NET Framework, ASP.NET ran as SYSTEM, an inherently less secure setting. Use defense in depth. Place check points within each of the layers and subsystems within your application. The check points are the gatekeepers that ensure that only authenticated and authorized users are able to access the next downstream layer. Don't trust user input. Applications should thoroughly validate all user input before performing operations with that input. The validation may include filtering out special characters. This preventive measure protects the application against accidental misuse or deliberate attacks by people who are attempting to inject malicious commands into the system. Common examples include SQL injection attacks, script injection and buffer overflow. Use secure defaults. A common practice among developers is to use reduced security settings, simply to make an application work. If your application demands features that force you to reduce or change default security settings, test the effects and understand the implications before making the change. Don't rely on security by obscurity. Trying to hide secrets by using misleading variable names or storing them in odd file locations does not provide security. In a game of hide-and-seek, it's better to use platform features or proven techniques for securing your data. Check at the gate. You don't always need to flow a user's security context to the back end for authorization checks. Often, in a distributed system, this is not the best choice. Checking the client at the gate refers to authorizing the user at the first point of authentication (for example, within the Web application on the Web server), and determining which resources and operations (potentially provided by downstream services) the user should be allowed to access. If you design solid authentication and authorization strategies at the gate, you can circumvent the need to delegate the original caller's security context all the way through to your application's data tier. Assume external systems are insecure. If you don't own it, don't assume security is taken care of for you. Reduce surface area. Avoid exposing information that is not required. By doing so, you are potentially opening doors that can lead to additional vulnerabilities. Also, handle errors gracefully; don't expose any more information than is required when returning an error message to the end user. Fail to a secure mode. If your application fails, make sure it does not leave sensitive data unprotected. Also, do not provide too much detail in error messages; meaning don't include details that could help an attacker exploit a vulnerability in your application. Write detailed error information to the Windows event log. Remember you are only as secure as your weakest link. Security is a concern across all of your application tiers. If you don't use it, disable it. You can remove potential points of attack by disabling modules and components that your application does not require. For example, if your application doesn't use output caching, then you should disable the ASP.NET output cache module. If a future security vulnerability is found in the module, your application is not threatened.

45 Ataque de DJ Hell

46 Policies, Procedures, and Awareness
Physical Security Perimeter Internal Network Host Application Data Defensas de Perímetro

47 Policies, Procedures, and Awareness
Physical Security Perimeter Internal Network Host Application Data Defensas de Red

48 Policies, Procedures, and Awareness
Physical Security Perimeter Internal Network Host Application Data Defensa de Host

49 Policies, Procedures, and Awareness
Physical Security Perimeter Internal Network Host Application Data Defensa de Aplicación

50 Policies, Procedures, and Awareness
Defensa de Datos Policies, Procedures, and Awareness Physical Security Perimeter Internal Network Host Application Data

51 Ataque de Sitio Web: DJ Hell
Compromiso de sitio web Problemas en algunas capas de Seguridad Los servidores web no estaban debidamente actualizado (parches) Claves de administrador no actualizadas Métodos de acceso: Capa de Aplicación 1 aplicación de consulta no utilizaba estándar de autenticación para consulta de datos. Capa de Datos Concepto de mínimo privilegio no utilizado “SysAdmin”

52 Ataque de Sitio Web: DJ Hell
INTENTO ACCESO :40:24 SERVERIP GET /msib21/APPHACKED/Capitulo.asp cod=02update%20IS_AREST%20set%20EST_Descripcion%20=%20%27Hacked%20By%20DjHell%27--|32|80040e14|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Line_1:_Incorrect_syntax_near_'Hacked'. 80 – IPATTACKER libwww-perl/ MODIFICACION DE CODIGO : :37:25 SERVERIP GET /msib21/APPHACKED/NotasCapitulo.asp cod=01update%20IS_AREST%20set%20EST_Descripcion%20=%20%27Hacked%20By%20DjHell% SERVERIP libwww-perl/ 7:25 SERVERIP GET /msib21/APPHACKED/NotasCapitulo.asp cod=01update%20IS_AREST%20set%20EST_Descripcion%20=%20%27Hacked%20By%20DjHell% libwww-perl/ SQL Code Injection

53 Ataque de Sitio Web: DJ Hell
Code Review of ASP pages from customer's server: ========================================= line 7 of /_Conexi.asp: conn.Open = "DSN=APPHACKED;UID=adminAPP;PWD=XXXXX" line 2 of /NotasCapitulo.asp <!--#include file="_Conexi.asp"--> line 11 of /Capitulo.asp sql = "select EST_DATA1, EST_Notas from IS_AREST where EST_DATA = " & cod Line 11 allows for SQL Injection...making the following request will cause the exact same behavior the customer originally reported: UPDATE IS_AREST SET EST_Descripcion = 'Hacked By SQLInjection' SQL Code Injection

54 Herramienta FXCop

55 FXCop Herramienta FXCop http://www.gotdotnet.com/team/fxcop/
Diseño de librerías Localización Convención de Nombres Desempeño Seguridad

56 Referencias Herramienta FXCop
Modelo de análisis de Amenazas (Threat Modeling) Pagina General de Seguridad Sitio para Seguridad de desarrollo Sitio de seguridad de MSDN para desarrolladores Guías de mejores practicas Guías Patterns & Practices Ejemplos de programación seguro “Writing Secure Code, 2nd edition” Howard, Leblanc. MS Press, 2003

57 © 2003 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.