La seguridad de los desarrollos en tecnologías de la información

Partiendo del marco de la adecuación a lo previsto en el Esquema Nacional de Seguridad , establecido en la ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los servicios públicos y la necesidad de las empresas de tecnologías de la información de buscar la mejora continua en sus procesos de desarrollo software, para satisfacer las necesidades de la Administración y por extensión de los clientes privados.

Hoy recogemos algunos aspectos en los que Bilbomática se encuentra trabajando para desarrollar y mantener aplicaciones confiables.

Una buena referencia es la OWASP™ Foundation the free and open software security community  y en concreto el proyecto OWASP Application Security Verification Standard (ASVS) que proporciona una base para probar los controles técnicos de seguridad de las aplicaciones y también proporciona a los desarrolladores una lista de requisitos para el desarrollo seguro. Permitiendo normalizar el rango de cobertura y el nivel de rigor a la hora de realizar la verificación de seguridad de aplicaciones  utilizando un estándar abierto. El estándar proporciona una base de seguridad técnica de las aplicaciones, en el que se confíe para protegerse contra vulnerabilidades como el Cross-Site Scripting (XSS) y la inyección SQL. Este estándar puede utilizarse para establecer un nivel de confianza en la seguridad de las aplicaciones.

Principalmente, proporcionando a los desarrolladores un criterio con el que evaluar el grado de confianza que se puede depositar en los desarrollos realizados, orientando cómo incluir controles de seguridad para satisfacer los requisitos de seguridad de las aplicaciones y especificando los requisitos de verificación de la seguridad.

El Application Security Verification Standard (ASVS) se encuentra en la actualidad en su versión 4.0. y recoge tres niveles de verificación de seguridad de las aplicaciones:

- Nivel 1 es para niveles de seguridad bajos y es completamente comprobable de penetración.

- Nivel 2 es para aplicaciones que contienen datos confidenciales, lo que requiere protección y es el nivel recomendado para la mayoría de las aplicaciones.

- Nivel 3 es para las aplicaciones más críticas - aplicaciones que realizan transacciones de alto valor, contienen datos médicos sensibles, o cualquier aplicación que requiera el más alto nivel de confianza.

Cada nivel de ASVS contiene una lista de requisitos de seguridad y cada uno de estos requisitos también dispone de características y capacidades específicas de seguridad que deberemos incorporar al software.

La arquitectura de seguridad en ASVS cubre los aspectos más importantes de este ámbito, como son: disponibilidad, confidencialidad, integridad, no repudio y privacidad.

Cada uno de estos principios de seguridad lo incorporaremos en todos los desarrollos de forma natural al proceso de construcción de software y garantizaremos que todos los controles de seguridad estén presentes y sean funcionales. Teniendo en cuenta los aspectos detallados en los requisitos de verificación:

Como ejemplo en V13 Requisitos de verificación de API y servicios web, el objetivo es controlar y asegurar de que una aplicación que utiliza APIs en la capa de servicio  (normalmente utilizando JSON, XML o GraphQL) lo hace de forma segura en los aspectos de:

- Autenticación, gestión de sesiones y autorización de todos los servicios web.
- En la validación de las entradas de todos los parámetros que se envíen.
- Controles de seguridad eficaces para todos los tipos de API.

Estableciendo cuatro subniveles de clasificación de las verificaciones a realizar:

V13.1 Requisitos genéricos de verificación de seguridad del servicio web
V13.2 Requisitos de Verificación del Servicio Web RESTful
V13.3 Requisitos de Verificación de Servicios Web SOAP
V13.4 GraphQL y otros requisitos de seguridad de la capa de datos de servicios web

Por ultimo, os dejamos un interesante articulo "Hacking JSON Web Tokens (JWTs). And how attackers forge tokens and log in as someone else" publicado en Medium.com por Vickie Li, que permite entrar de lleno en la complejidad de la seguridad y las buenas prácticas en las implementaciones software.





Algunos links de referencia:

Application Security Verification Standard 4.0

https://www.owasp.org/index.php/Category:Java

https://www.owasp.org/index.php/Category:OWASP_.NET_Project

https://www.owasp.org/index.php/Category:OWASP_Download

Read More

FHIR a por la Release 4 - Congreso HL7 International Madrid del 6 al 12 de Mayo

Hoy recogemos el congreso HL7 International que por primera vez se realiza en Madrid del 6 al 12 de Mayo , con el objetivo de avanzar en la interoperabilidad de datos en torno a la sanidad. En este congreso también se trata de determinar el alcance y la prioridad de la nueva versión de FHIR Release 4.

 - Normative: push to normative for

• •  -Foundation / API / XML / JSON / Bundle / OperationOutcome
  •  -Terminology Service (ValueSet / CodeSystem / ExpansionProfile)
  •  -StructureDefinition / CapabilityStatement
  •  -Patient / RelatedPerson / Practitioner / Organization / ?Endpoint
• - Position a core set of clinical resources (‘health base’?) for normative in R5 (or Observation | AllergyIntolerance | MedicationStatement normative for R4?)
• -JSON: ? use manifest for extensions, parameters resource (see blog post) (note that discussion on this didn’t go very well – probably will be dropped)
• -RDF: more ontology bindings + resolve status of JSON-LD
•  Data Analytics: support for a bulk data analysis bridge format (Apache Parquet?)
• -API: better control over retrieving graphs, and value added query support (tabular format?)
• -Patterns: change the W5 framework to a pattern (logical model), tie the patterns to ontology, and use of patterns to drive more consistency (and how to do this without decreasing quality)
• -Services: more services. Candidates: conformance, registry, personal health summary?, etc?
• -Deployment: get a clear standards path for smart on fhir / cds-hooks (and alignment with UMA/Heart)
• -FM: work on alignment between FM resources and the rest of FHIR

Please note that this list is written anticipating that the normal standards development process occur, and the content as a whole is maintained. I’d expect that this would amount to 1,000s of tasks. So this list is not a list of ‘what will change in R4’, but an indication of where particular focus will be applied by the FHIR leadership (so don’t be concerned if a particular issue of yours is not on this list, as long as it’s in gForge)."

Os dejamos la Agenda de los eventos de Aprendizaje  

Health Level Seven® International

May 2017 HL7 International Conference & Working Group Meeting Madrid Marriott Auditorium Hotel & Conference Center, Madrid, Spain May 6-12, 2017

http://www.hl7.org/events/working_group_meeting/2017/05/

Noticias relacionadas:

Computer World

Read More