One Article Review

Accueil - L'article:
Source NoticeBored.webp NoticeBored
Identifiant 2148828
Date de publication 2020-09-04 14:26:51 (vue: 2021-01-06 20:37:56)
Titre NBlog Sept 4 - standardising ISMS data interfaces
Texte We've been chatting on the ISO27k Forum lately about using various IT systems to support ISO27k ISMSs. This morning, in response to someone saying that a particular tool which had been recommended did not work for them, Simon Day made the point that "Each organisation trying to implement an ISMS will find it's own way based on their requirements."Having surveyed the market for ISMS products recently, I followed-up with my usual blurb about organisations having different information risks and business situations, hence their requirements in this area are bound to differ, and in fact vary dynamically (in part because organisations mature as they gain experience with their ISMS: their needs change). The need for flexibility is why the ISO27k standards are so vague (essentially: figure out your own requirements by identifying and evaluating your information risks using the defined governance structure - the ISMS itself), rather than explicitly demanding particular security controls (as happens with PCI-DSS). ISO27k is designed to apply to any organisation. That thought sparked a creative idea that I've been contemplating ever since: wouldn't it be wonderful if there was a standard for the data formats allowing us to migrate easily between IT systems supporting ISO27k ISMSs?I'm idly thinking about a standard file format with which to specify information risks (threats, vulnerabilities, impacts and probabilities), controls, policies, procedures, metrics, objectives etc. - maybe an XML schema with specified field names and (where applicable) enumerated lists of values.Aside from migrating between ISMS IT support systems and services, standard data formats would facilitate data sharing between application systems, services or sub-functions (e.g. for vulnerability management, incident management and information risk management), and between departments or even organisations (e.g. insurance companies, auditors and advisors and their clients and partners).Perhaps we should develop an outline specification and propose such a standard to ISO/IEC JTC1 SC 27. A New W
Envoyé Oui
Condensat  for  that about add advisors allowing already any applicable application apply are area aside auditors based basic because been being between blurb bound business change chatting clear clients companies contemplating controls creative data day defined demanding departments designed details develop developing did differ different draft dss dynamically each ease easily else enumerated essentially: etc evaluating even ever expanding experience explicitly facilitate fact field figure file find flexibility followed format formats forum lately from functions gain general generating governance had happens having hence idea identifying idly impacts implement incident information insurance interfaces is why isms isms: ismss iso/iec iso27k item itself jtc1 list lists made management market mature maybe an metrics migrate migrating morning names nblog need needs new not objectives organisation organisations out outline own part particular partners pci perhaps point policies probabilities procedures process products proposal propose proposed rather recently recommended requirement requirements researching response risk risks saying schema schemas security sept services sharing should simon since: wouldn situations someone something sparked specification specified specify standard standardising standards starting structure sub such sufficient support supporting surveyed systems than that them thinking thought threats tool topic trying using usual vague values various vary vulnerabilities vulnerability way what where which why will wonder wonderful work would xml your
Tags Tool Vulnerability
Stories
Notes
Move


L'article ne semble pas avoir été repris aprés sa publication.


L'article ne semble pas avoir été repris sur un précédent.
My email: