Pragmatic Ontology for Information Security Management

Collective construction of a pragmatic information security ontology.

Goals

• Minimal (Only necessary concepts)
• Manager-oriented (gaps-aware)
• Customizable by local individuals (Fosterable)
• Referencing basics concepts (Understable)
• Open (Free access)
• Shared (Commentable and revisable)

Please reference as:

Cares, C; Diéguez, M; López-Fenner, J. PrISMO: A Pragmatic Information Security 
Management Ontology
In Serene-risc Annual Workshop 2021, Cánada, 21-22 May 2021.

<?xml version="1.0"?> <rdf:RDF xmlns:owl ="http://www.w3.org/2002/07/owl#" xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd ="http://www.w3.org/2001/XMLSchema#" > <!-- validar cambios en https://www.w3.org/RDF/Validator/rdfval --> <owl:Ontology rdf:about=""> <rdfs:comment>An example OWL ontology</rdfs:comment> <!-- owl:imports rdf:resource="http://www.mydomain.org/persons"/ --> <rdfs:label>University Ontology</rdfs:label> </owl:Ontology> <owl:Class rdf:ID="Information-Security-Standard"/> <owl:Class rdf:ID="Asset"/> <owl:Class rdf:ID="Information-Asset"> <rdfs:subClassOf rdf:resource="#Asset" /> </owl:Class> <owl:Class rdf:ID="Agent"/> <owl:Class rdf:ID="Organizational-Unit"> <rdfs:subClassOf rdf:resource="#Agent" /> </owl:Class> <!-- este no estaba en el diagrama pero "atacantes# aparecen en las otras ontologías así que mejor considerarlo y estudiar mejor como hacerlo consistente con riesgo, en el sentido que en el momento de un ataque, el activo a proteger puede que aún esté protegido, es decir que el riesgo aún sea riesgo, y sí puede que exista un atacante.--> <owl:Class rdf:ID="Attacker"> <rdfs:subClassOf rdf:resource="#Agent" /> </owl:Class> <!-- Esto es nuevo y en realidad no lo he pensado mucho, pero creo que parte de la gestión es gestionar los posibles atacantes, principalmente en los internos peligrosos. Hay que pensarlo --> <owl:Class rdf:ID="Risky-Agent"> <rdfs:subClassOf rdf:resource="#Agent" /> </owl:Class> <owl:Class rdf:ID="Risk"/> <owl:Class rdf:ID="Information-Asset-Risk"> <rdfs:subClassOf rdf:resource="#Risk" /> </owl:Class> <owl:Class rdf:ID="Safeguard"/> <owl:Class rdf:ID="Control"> <rdfs:subClassOf rdf:resource="#Safeguard" /> </owl:Class> <!-- esto la agregue para asegurarnos que, desde la perspectiva de "logro" de la seguridad quede como en ingeniería de software, es decir, como el cumplimiento de requerimientos no funcionales --> <owl:Class rdf:ID="Non-functional-Requirement"/> <owl:Class rdf:ID="Security-Requirement"> <rdfs:subClassOf rdf:resource="#Non-functional-Requirement"/> </owl:Class> <!-- En el UML los teníamos como "enumeration" pero siempre los nombres de enumeraciones son nombres que simbolizan un tipo, entonces es mejor que sean subclases y no individuos por si apaecen atributos que darle a los miembros del tipo, sobre todo pensandos que, aún siendo NFR, podrían (dben) ser en algún momento "mesuarables" --> <owl:Class rdf:ID="Confindentiality"> <rdfs:subClassOf rdf:resource="#Security-Requirement"/> </owl:Class> <owl:Class rdf:ID="Availability"> <rdfs:subClassOf rdf:resource="#Security-Requirement"/> </owl:Class> <owl:Class rdf:ID="Integrity"> <rdfs:subClassOf rdf:resource="#Security-Requirement"/> </owl:Class> <owl:Class rdf:ID="Information-Security-Objective"/> <owl:Class rdf:ID="Information-Security-Domain" /> <owl:Class rdf:ID="Threat"/> <owl:Class rdf:ID="Vulnerability"/> <!-- le cambié nombre a "has" algo porque quizás todos los "has" podrían tener alguna característica coḿún para posteriores inferencias --> <owl:ObjectProperty rdf:ID="hasSubcontrol"> <rdfs:domain rdf:resource="#Control"/> <rdfs:range rdf:resource="#Control"/> </owl:ObjectProperty> <!-- OJO modo de definir una propiedad inversa --> <!-- ***************************************** --> <owl:ObjectProperty rdf:ID="parentControl"> <owl:inverseOf rdf:resource="#hasSubcontrol" /> <rdfs:domain rdf:resource="#Control"/> <rdfs:range rdf:resource="#Control"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="itsControls"> <rdfs:domain rdf:resource="#Information-Security-Domain"/> <rdfs:range rdf:resource="#Control"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="requires"> <rdfs:domain rdf:resource="#Information-Asset"/> <rdfs:range rdf:resource="#Security-Requirement"/> </owl:ObjectProperty> <!-- OJO Modo de definir una cardinalidad --> <!-- ************************************ --> <owl:Class rdf:about="#Information-Security-Domain" > <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#itsControls"/> <owl:minCardinality rdf:datatype="xsd:NonNegativeInteger">2</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Information-Asset" > <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#requires"/> <owl:minCardinality rdf:datatype="xsd:NonNegativeInteger">1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <!-- No está en el diagrama pero lo habíamos trabajado así antes--> <owl:ObjectProperty rdf:ID="itsMainControl"> <rdfs:domain rdf:resource="#Information-Security-Standard"/> <rdfs:range rdf:resource="#Control"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="mitigates"> <rdfs:domain rdf:resource="#Control"/> <rdfs:range rdf:resource="#Risk"/> </owl:ObjectProperty> <!-- falta definir mitigatedBy como inversa de esta --> <!-- esto es el implemented after/before porque ciertos controles se apoyan en otros controles, por ejemplo, en la política de seguridad o (esto es feo) lo que dice la política de seguridad ne particular, posibilidad que no hemos modelado --> <owl:ObjectProperty rdf:ID="requires"> <rdfs:domain rdf:resource="#Control"/> <rdfs:range rdf:resource="#Control"/> </owl:ObjectProperty> <!-- en el modelo se llama threats pero leer "trheats" una "Threat" es raro porque, en realidad, un potencial atacante sólo "configura" una amenaza --> <owl:ObjectProperty rdf:ID="enables"> <rdfs:domain rdf:resource="#Risky-Agent"/> <rdfs:range rdf:resource="#Threat"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="causes"> <rdfs:domain rdf:resource="#Information-Asset-Risk"/> <rdfs:range rdf:resource="#Threat"/> </owl:ObjectProperty> <!-- definir effect como inversa de esta --> <owl:ObjectProperty rdf:ID="allows"> <rdfs:domain rdf:resource="#Vulnerability"/> <rdfs:range rdf:resource="#Threat"/> </owl:ObjectProperty> <!-- definir exploits como inversa de esta --> <owl:ObjectProperty rdf:ID="protects"> <rdfs:domain rdf:resource="#Safeguard"/> <rdfs:range rdf:resource="#Information-Asset"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="affects"> <rdfs:domain rdf:resource="#Vulnerability"/> <rdfs:range rdf:resource="#Information-Asset"/> </owl:ObjectProperty> <!-- falta definir exhibits como inversa de esta. Además creo que hay que hacer la diferencia entre assets tangibles e intangibles, cuales son de información y cuáles son parte de la infraestrcutura de seguridad, ya sean tangibles o intangibles --> <!-- individuals --> <owl:Thing rdf:ID="Patients_Names"/> <owl:Thing rdf:ID="Confidential_to_doctors" /> <owl:Thing rdf:about="#Confidential_to_doctors" > <rdf:type rdf:resource="#Confindentiality"/> </owl:Thing> <owl:Thing rdf:about="#Patients_Names" > <rdf:type rdf:resource="#Information-Asset"/> <requires rdf:resource="#Confidential_to_doctors" /> </owl:Thing> <owl:Thing rdf:ID="Providers_Names" /> <owl:Thing rdf:about="#Providers_Names" > <rdf:type rdf:resource="#Information-Asset"/> </owl:Thing> <owl:Thing rdf:ID="Metal_detector_input_barrier" /> <owl:Thing rdf:about="#Metal_detector_input_barrier" > <rdf:type rdf:resource="#Control"/> </owl:Thing> </rdf:RDF>
Download