{"id":76,"date":"2023-03-11T15:45:57","date_gmt":"2023-03-11T15:45:57","guid":{"rendered":"http:\/\/192.168.0.7\/wordpress\/?page_id=76"},"modified":"2023-03-30T09:34:03","modified_gmt":"2023-03-30T09:34:03","slug":"standardization-principles","status":"publish","type":"page","link":"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/","title":{"rendered":"Standardization principles"},"content":{"rendered":"\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_47_1 ez-toc-wrap-right counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\">Table of Contents<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"ez-toc-toggle-icon-1\"><label for=\"item-64707e1d32a2a\" aria-label=\"Table of Content\"><span style=\"display: flex;align-items: center;width: 35px;height: 30px;justify-content: center;direction:ltr;\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/label><input  type=\"checkbox\" id=\"item-64707e1d32a2a\"><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Introduction\" title=\"Introduction\">Introduction<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Perimeter_Cyber_and_Physical_incidents\" title=\"Perimeter : Cyber and Physical incidents.\">Perimeter : Cyber and Physical incidents.<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Purpose_Incident_detection\" title=\"Purpose : Incident detection.\">Purpose : Incident detection.<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Adoption_Definition_of_IDMEFv2_focuses_on_%E2%80%9Cadoption%E2%80%9D\" title=\"Adoption : Definition of IDMEFv2 focuses on &#8220;adoption&#8221;.\">Adoption : Definition of IDMEFv2 focuses on &#8220;adoption&#8221;.<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Minimize_the_learning_curve\" title=\"Minimize the learning curve\">Minimize the learning curve<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Usability\" title=\"Usability\">Usability<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Simplicity_vs_exhaustivity\" title=\"Simplicity vs exhaustivity\">Simplicity vs exhaustivity<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Agnostic_format_classes_and_attributes\" title=\"Agnostic format, classes and attributes\">Agnostic format, classes and attributes<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Attribute_Enumeration\" title=\"Attribute Enumeration\">Attribute Enumeration<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Theory_AND_practice\" title=\"Theory AND practice\">Theory AND practice<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Avoid_the_NIH_syndrome\" title=\"Avoid the NIH syndrome\">Avoid the NIH syndrome<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Ecosystem_interoperability\" title=\"Ecosystem &amp; interoperability\">Ecosystem &amp; interoperability<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Legacy\" title=\"Legacy\">Legacy<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#End_to_end_format_From_the_probe_to_the_operator\" title=\"End to end format : From the probe to the operator.\">End to end format : From the probe to the operator.<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-15\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Modularity\" title=\"Modularity\">Modularity<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-16\" href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#Cope_with_the_past_and_prepare_the_future\" title=\"Cope with the past and prepare the future\">Cope with the past and prepare the future<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Introduction\"><\/span>Introduction<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Proposing a new standard is a tough and uncertain task. A standard has to be complex enough to please everyone and simple enough to frighten no one. IDMEFv2 mixes multiple concepts cyber and physical. But IDMEFv2 can potentially be used by a lot of different type of users, security tools developers , integrators, operators, \u2026 so it&#8217;s ease of adoption is very important. <\/p>\n\n\n\n<p>To facilitate people contribution and consensus we have defined some principles we are trying to follow to define IDMEFv2.<\/p>\n\n\n\n<p>PS: Those principles can still be discussed as we are working on the very first version of the format.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Perimeter_Cyber_and_Physical_incidents\"><\/span>Perimeter : Cyber and Physical incidents.<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>IDMEFv1 was covering cyber intrusion, IDMEFv2 covers cyber and physical incidents.<\/p>\n\n\n\n<p>This is probably the most disruptive principle of IDMEFv2. IDMEFv2 first drafts have been designed in a &#8220;real life&#8221; architecture for protection of critical infrastructures. During those pilot it appeared as obvious that there was a need for standardisation of message exchange between cyber detection analyser and managers, there was also a very similar need between physical detection analyser and managers and most important there was a need of message exchange between cyber and physical detection architecture for detection of complex and combined scenarios of attacks or simply of chained incidents. Therefore we had two choices , first choice was to define two dedicated standards, a cyber incident detection format and a physical incident detection format, able to interoperate, the second choice was to define one single standard for the two domains. Concepts being so close and the frontier between cyber and physical world being inexorably fading away we choose the second option, one standard for all.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Purpose_Incident_detection\"><\/span>Purpose : Incident detection.<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>The purpose of IDMEFv2 is incident detection. To keep it simple IDMEFv2 should be composed of classes and attributes for incident detection only.<\/p>\n\n\n\n<p>Thus it&#8217;s important to keep in mind what IDMEFv2 is not :<\/p>\n\n\n\n<ul>\n<li><strong>IDMEFv2 is not a universal log or event format.<\/strong> It describes only event of interest in regards of incident detection. It doesn&#8217;t and can&#8217;t replace all existing log format.<\/li>\n\n\n\n<li><strong>IDMEFv2 is not an incident analysis format.<\/strong> It doesn&#8217;t replace IODEFv2 (Incident Object Definition Exchange Format). IDMEFv2 can help create a IODEFv2 message. It can also be joint as an attachment to a IODEFv2 message to offer technical details.<\/li>\n\n\n\n<li><strong>IDMEFv2 is not a &#8220;trouble ticketing&#8221; or &#8220;case&#8221; format.<\/strong> When an incident is detected, the operator might need to &#8220;open a case&#8221; so the incident can be resolved. This needs to be done in a ticketing tool. An IDMEFv2 message can be attached to a ticket but should not contains information about case resolution (e.g. owner, status, priority, history, etc.) . It may contain a &#8220;Ticket ID&#8221; attribute to point toward an external ticket system.<\/li>\n\n\n\n<li><strong>IDMEFv2 is not a Threat Intelligence format.<\/strong> IDMEFv2 might contains information for threat intelligence expert , it can transport Threat Intelligence personalised information but it doesn&#8217;t replace dedicated threat intelligence format like STIX.<\/li>\n<\/ul>\n\n\n\n<p>IDMEFv2 should store information for incident detection. After an incident has been detected it might be necessary for the operator\/analyst to fetch information that are available in raw logs for example but not stored in IDMEFv2. Although the limit is not always clear, IDMEFv2 attributes should not store information that are only useful for analysis and not for detection. First we don&#8217;t want to replace existing standards, secondly a format which would try to solve all problems (logging, detection, analysis, etc) is destined to fail.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Adoption_Definition_of_IDMEFv2_focuses_on_%E2%80%9Cadoption%E2%80%9D\"><\/span>Adoption : Definition of IDMEFv2 focuses on &#8220;adoption&#8221;.<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>It seems obvious but can be sometime forgotten in the middle of heavy technical discussion.<\/p>\n\n\n\n<p>We ARE NOT aiming everyone 100 % satisfaction, we are aiming <strong>consensus<\/strong>, <strong>compromise<\/strong> and <strong>simplicity<\/strong> for a wide adoption.<\/p>\n\n\n\n<p>Adoption is not necessary synonym of complexity or exhaustivity.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Minimize_the_learning_curve\"><\/span>Minimize the learning curve<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Incident (and intrusion) detection is a complex field. The recent rise of IoT and IIoT makes it even more complex adding new potential attack surfaces. One has to learn a lot of concepts to deploy efficient incident detection systems. IDMEFv2 needs to be easy to learn and to implement. It should manipulate essentially widespread concepts and at the same time leave optional ways of dealing with very complex needs.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Usability\"><\/span>Usability<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>The same way as &#8220;learning curve principle&#8221;, IDMEFv2 should manipulate widespread and easy to deploy technologies.<\/p>\n\n\n\n<p>This principle partly led us to choose JSON representation as well as HTTPs for transport implementation. Nowadays JSON is widely adopted and specially in incident detection tools, log management console and NOSQL database. HTTP is obviously one of the most used and popular Internet protocol. Other format and transport are possible but we will focus on those two choices first.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Simplicity_vs_exhaustivity\"><\/span>Simplicity vs exhaustivity<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Following the &#8220;Less is more&#8221; quote as well a the KISS method (Keep It Simple, Stupid) IDMEFv2 should be as simple as possible, while still answering all the needs.<\/p>\n\n\n\n<p>IDMEFv1 was very exhaustive : 33 classes, 108 attributes, 260 possible combinations, potential infinite recursivity, etc. In theory this could be an advantage but in practice it had many disadvantage : long learning curve, complex code implementation, more misinterpretation, \u2026 This REX led to a much smaller number of classes and attributes in IDMEFv2.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Agnostic_format_classes_and_attributes\"><\/span>Agnostic format, classes and attributes<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>To respect most of the principles we have already presented IDMEFv2 classes and attributes should be as agnostic as possible. We are not creating a format composed of cyber classes\/attributes and physical classes\/attributes. We need to use concept and define classes and attributes that can be used indifferently in the two domains as much as possible.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Attribute_Enumeration\"><\/span>Attribute Enumeration<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>As often as possible, IDMEFv2 must propose enumeration for attributes value.<\/p>\n\n\n\n<p>The purpose of standardizing incident detection message exchange goes beyond the simple exchange of information between analyser and managers. Alerts must be compared, analyzed, aggregated, correlated, etc. Thus it is important that some attributes propose &#8220;closed list&#8221; values other wise comparison\/filtering\/ordering is impossible. This is a difficult choice as &#8220;closed enumeration lists&#8221; are always limited and frustrating but this is essential. Means will be proposed to extend the close list if essential.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Theory_AND_practice\"><\/span>Theory AND practice<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Many theoretically very good standards have failed when confronted to reality. IDMEFv2 must avoid this pitfall. IDMEFv2 has been tested in real situation during the first stage of it&#8217;s definition. Today, libraries and tools are available to continue testing as the definition is being tuned.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Avoid_the_NIH_syndrome\"><\/span>Avoid the NIH syndrome<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Fight the NIH (Not Invented Here) syndrome<\/p>\n\n\n\n<p>Incident detection is not a brand new field. There is a lot of existing formats which cover part of the problem. It is important when possible to reuse existing concepts which have already proven to be efficient. During the analysis phase, many different log\/event\/incident\/alert formats have been studied to extract interesting concepts. Among others, IDMEFv2 reuses concepts, classes or attributes from :<\/p>\n\n\n\n<ul>\n<li>IDMEFv1 : Intrusion Detection Message Exchange Format v1<\/li>\n\n\n\n<li>IODEF v2 : Incident Object Definition Exchange Format<\/li>\n\n\n\n<li>IDEA : Intrusion Detection Extensible Alert<\/li>\n\n\n\n<li>Log Management and SIEM tools IBM (Leef), HP (CEF) , Splunk, Elastic (ECS), Logpoint<\/li>\n\n\n\n<li>RIST &#8211; ENISA : Reference Security Incident Taxonomy<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Ecosystem_interoperability\"><\/span>Ecosystem &amp; interoperability<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Incident detection is a part of a more global puzzle using other exchange formats. IDMEFv2 has to feet correctly in this larger architecture avoiding to overlap other format perimeter when it&#8217;s possible. IDMEFv2 should also interoperate with existing formats.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Legacy\"><\/span>Legacy<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>IDMEFv2 should be usable into existing architecture using proprietary formats. The ultimate goal would be that all detection tools, may they be analyser or managers, cyber or physical natively use the IDMEFv2 format, but obviously this can&#8217;t happen suddenly so it has to be &#8220;easily&#8221; possible to start using IDMEFv2 in an existing system without having to change all it&#8217;s component at once.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"End_to_end_format_From_the_probe_to_the_operator\"><\/span>End to end format : From the probe to the operator.<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>IDMEFv2 alerts are created by analyzers and sent to managers. But the life of an alert doesn&#8217;t end when it&#8217;s received by a manager. It can be correlated, aggregated, stored, indexed, etc. and then it will be displayed to operators in a GUI (Graphical User Interface). It might even be used to created other messages in other format. This end to end usage has to be taken in consideration while designing the format: from the analyzer to the operator.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Modularity\"><\/span>Modularity<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>One should be able to use only some parts of IDMEFv2<\/p>\n\n\n\n<p>IDMEFv2 aim to cover all type of incident detection : Cyber , Physical, Availability and also Cyber Threats, Natural Hazard Threats, etc. It is very important that IDMEFv2 can be used on smaller perimeters.<\/p>\n\n\n\n<p>As examples :<\/p>\n\n\n\n<ul>\n<li>IDMEFv2 can be used in a full cyber intrusion detection architecture with no physical detectors nor sensors.<\/li>\n\n\n\n<li>IDMEFv2 can be used in a full physical incident detection architecture with no cyber detectors nor censors<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Cope_with_the_past_and_prepare_the_future\"><\/span>Cope with the past and prepare the future<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>IDMEFv2 must be able to deal with all the existing concept in incident detection but also leave room for incident detection evolution in the future.<\/p>\n\n\n\n<p>As already mentioned bellow, the field of incident detection, at least for the cyber part, isn&#8217;t new and concepts are already used. IDMEFv2 must be able to interoperate with all this past. On the other end, standardising a format is a long task that can&#8217;t be renewed frequently. The field of incident detection is evolving very fast : rise of IoT and IIoT, growth of cyber-criminality, new types of attacks, smart-&#8220;everything&#8221;, etc. Organisations must also be prepared to face natural hazard threats and incidents rise due to climate change. IDMEFv2 must anticipate all those needs.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introduction Proposing a new standard is a tough and uncertain task. A standard has to be complex enough to please everyone and simple enough to frighten no one. IDMEFv2 mixes multiple concepts cyber and physical. But IDMEFv2 can potentially be used by a lot of different type of users, security tools developers , integrators, operators,&hellip;&nbsp;<a href=\"https:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/\" class=\"\" rel=\"bookmark\">Read More &raquo;<span class=\"screen-reader-text\">Standardization principles<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":""},"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v20.6 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Standardization principles - Task Force<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Standardization principles - Task Force\" \/>\n<meta property=\"og:description\" content=\"Introduction Proposing a new standard is a tough and uncertain task. A standard has to be complex enough to please everyone and simple enough to frighten no one. IDMEFv2 mixes multiple concepts cyber and physical. But IDMEFv2 can potentially be used by a lot of different type of users, security tools developers , integrators, operators,&hellip;&nbsp;Read More &raquo;Standardization principles\" \/>\n<meta property=\"og:url\" content=\"http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/\" \/>\n<meta property=\"og:site_name\" content=\"Task Force\" \/>\n<meta property=\"article:modified_time\" content=\"2023-03-30T09:34:03+00:00\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data1\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/\",\"url\":\"http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/\",\"name\":\"Standardization principles - Task Force\",\"isPartOf\":{\"@id\":\"https:\/\/192.168.0.7\/wordpress\/#website\"},\"datePublished\":\"2023-03-11T15:45:57+00:00\",\"dateModified\":\"2023-03-30T09:34:03+00:00\",\"breadcrumb\":{\"@id\":\"http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"http:\/\/192.168.0.7\/wordpress\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Standardization principles\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/192.168.0.7\/wordpress\/#website\",\"url\":\"https:\/\/192.168.0.7\/wordpress\/\",\"name\":\"IDMEFv2 Web Site\",\"description\":\"IDMEFv2 Standardization Task Force Website\",\"publisher\":{\"@id\":\"https:\/\/192.168.0.7\/wordpress\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/192.168.0.7\/wordpress\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/192.168.0.7\/wordpress\/#organization\",\"name\":\"IDMEFv2 Task Force\",\"url\":\"https:\/\/192.168.0.7\/wordpress\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/192.168.0.7\/wordpress\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/192.168.0.7\/wordpress\/wp-content\/uploads\/2023\/03\/LogoIDMEFv2.png\",\"contentUrl\":\"https:\/\/192.168.0.7\/wordpress\/wp-content\/uploads\/2023\/03\/LogoIDMEFv2.png\",\"width\":200,\"height\":200,\"caption\":\"IDMEFv2 Task Force\"},\"image\":{\"@id\":\"https:\/\/192.168.0.7\/wordpress\/#\/schema\/logo\/image\/\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Standardization principles - Task Force","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/","og_locale":"en_US","og_type":"article","og_title":"Standardization principles - Task Force","og_description":"Introduction Proposing a new standard is a tough and uncertain task. A standard has to be complex enough to please everyone and simple enough to frighten no one. IDMEFv2 mixes multiple concepts cyber and physical. But IDMEFv2 can potentially be used by a lot of different type of users, security tools developers , integrators, operators,&hellip;&nbsp;Read More &raquo;Standardization principles","og_url":"http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/","og_site_name":"Task Force","article_modified_time":"2023-03-30T09:34:03+00:00","twitter_card":"summary_large_image","twitter_misc":{"Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/","url":"http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/","name":"Standardization principles - Task Force","isPartOf":{"@id":"https:\/\/192.168.0.7\/wordpress\/#website"},"datePublished":"2023-03-11T15:45:57+00:00","dateModified":"2023-03-30T09:34:03+00:00","breadcrumb":{"@id":"http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/"]}]},{"@type":"BreadcrumbList","@id":"http:\/\/192.168.0.7\/wordpress\/index.php\/standardization-principles\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"http:\/\/192.168.0.7\/wordpress\/"},{"@type":"ListItem","position":2,"name":"Standardization principles"}]},{"@type":"WebSite","@id":"https:\/\/192.168.0.7\/wordpress\/#website","url":"https:\/\/192.168.0.7\/wordpress\/","name":"IDMEFv2 Web Site","description":"IDMEFv2 Standardization Task Force Website","publisher":{"@id":"https:\/\/192.168.0.7\/wordpress\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/192.168.0.7\/wordpress\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/192.168.0.7\/wordpress\/#organization","name":"IDMEFv2 Task Force","url":"https:\/\/192.168.0.7\/wordpress\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/192.168.0.7\/wordpress\/#\/schema\/logo\/image\/","url":"https:\/\/192.168.0.7\/wordpress\/wp-content\/uploads\/2023\/03\/LogoIDMEFv2.png","contentUrl":"https:\/\/192.168.0.7\/wordpress\/wp-content\/uploads\/2023\/03\/LogoIDMEFv2.png","width":200,"height":200,"caption":"IDMEFv2 Task Force"},"image":{"@id":"https:\/\/192.168.0.7\/wordpress\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/192.168.0.7\/wordpress\/index.php\/wp-json\/wp\/v2\/pages\/76"}],"collection":[{"href":"https:\/\/192.168.0.7\/wordpress\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/192.168.0.7\/wordpress\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/192.168.0.7\/wordpress\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/192.168.0.7\/wordpress\/index.php\/wp-json\/wp\/v2\/comments?post=76"}],"version-history":[{"count":7,"href":"https:\/\/192.168.0.7\/wordpress\/index.php\/wp-json\/wp\/v2\/pages\/76\/revisions"}],"predecessor-version":[{"id":455,"href":"https:\/\/192.168.0.7\/wordpress\/index.php\/wp-json\/wp\/v2\/pages\/76\/revisions\/455"}],"wp:attachment":[{"href":"https:\/\/192.168.0.7\/wordpress\/index.php\/wp-json\/wp\/v2\/media?parent=76"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}