From 1b859e681685566f821025fb94fe8a3ce87705bf Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Wed, 11 Sep 2013 18:20:23 -0400 Subject: [PATCH 01/14] initial commit of stix validator script --- stix_validator/LICENSE.txt | 24 + stix_validator/README.md | 0 stix_validator/__init__.py | 0 stix_validator/schema/campaign.xsd | 209 ++ stix_validator/schema/course_of_action.xsd | 165 + stix_validator/schema/cybox/cybox_common.xsd | 2319 ++++++++++++ stix_validator/schema/cybox/cybox_core.xsd | 1090 ++++++ .../cybox/cybox_default_vocabularies.xsd | 3106 +++++++++++++++++ .../cybox/extensions/platform/README.txt | 1 + .../cybox/extensions/platform/cpe2.3.xsd | 40 + .../schema/cybox/objects/API_Object.xsd | 55 + .../schema/cybox/objects/Account_Object.xsd | 50 + .../schema/cybox/objects/Address_Object.xsd | 122 + .../schema/cybox/objects/Artifact_Object.xsd | 206 ++ .../schema/cybox/objects/Code_Object.xsd | 417 +++ .../schema/cybox/objects/Custom_Object.xsd | 43 + .../schema/cybox/objects/DNS_Cache_Object.xsd | 53 + .../schema/cybox/objects/DNS_Query_Object.xsd | 159 + .../cybox/objects/DNS_Record_Object.xsd | 87 + .../schema/cybox/objects/Device_Object.xsd | 55 + .../schema/cybox/objects/Disk_Object.xsd | 117 + .../cybox/objects/Disk_Partition_Object.xsd | 199 ++ .../cybox/objects/Email_Message_Object.xsd | 273 ++ .../schema/cybox/objects/File_Object.xsd | 359 ++ .../cybox/objects/GUI_Dialogbox_Object.xsd | 41 + .../schema/cybox/objects/GUI_Object.xsd | 40 + .../cybox/objects/GUI_Window_Object.xsd | 46 + .../cybox/objects/HTTP_Session_Object.xsd | 623 ++++ .../schema/cybox/objects/Library_Object.xsd | 114 + .../schema/cybox/objects/Link_Object.xsd | 24 + .../cybox/objects/Linux_Package_Object.xsd | 119 + .../schema/cybox/objects/Memory_Object.xsd | 70 + .../schema/cybox/objects/Mutex_Object.xsd | 40 + .../objects/Network_Connection_Object.xsd | 609 ++++ .../cybox/objects/Network_Flow_Object.xsd | 1559 +++++++++ .../cybox/objects/Network_Packet_Object.xsd | 2948 ++++++++++++++++ .../objects/Network_Route_Entry_Object.xsd | 155 + .../cybox/objects/Network_Route_Object.xsd | 93 + .../cybox/objects/Network_Socket_Object.xsd | 524 +++ .../cybox/objects/Network_Subnet_Object.xsd | 64 + .../schema/cybox/objects/PDF_File_Object.xsd | 601 ++++ .../schema/cybox/objects/Pipe_Object.xsd | 40 + .../schema/cybox/objects/Port_Object.xsd | 74 + .../schema/cybox/objects/Process_Object.xsd | 197 ++ .../schema/cybox/objects/Product_Object.xsd | 60 + .../schema/cybox/objects/Semaphore_Object.xsd | 50 + .../cybox/objects/Socket_Address_Object.xsd | 42 + .../schema/cybox/objects/System_Object.xsd | 409 +++ .../schema/cybox/objects/URI_Object.xsd | 62 + .../schema/cybox/objects/Unix_File_Object.xsd | 164 + .../Unix_Network_Route_Entry_Object.xsd | 56 + .../schema/cybox/objects/Unix_Pipe_Object.xsd | 36 + .../cybox/objects/Unix_Process_Object.xsd | 143 + .../objects/Unix_User_Account_Object.xsd | 78 + .../cybox/objects/Unix_Volume_Object.xsd | 41 + .../cybox/objects/User_Account_Object.xsd | 110 + .../cybox/objects/User_Session_Object.xsd | 60 + .../schema/cybox/objects/Volume_Object.xsd | 235 ++ .../schema/cybox/objects/Whois_Object.xsd | 456 +++ .../objects/Win_Computer_Account_Object.xsd | 135 + .../objects/Win_Critical_Section_Object.xsd | 40 + .../cybox/objects/Win_Driver_Object.xsd | 269 ++ .../cybox/objects/Win_Event_Log_Object.xsd | 137 + .../schema/cybox/objects/Win_Event_Object.xsd | 80 + .../objects/Win_Executable_File_Object.xsd | 1333 +++++++ .../schema/cybox/objects/Win_File_Object.xsd | 269 ++ .../cybox/objects/Win_Handle_Object.xsd | 186 + .../cybox/objects/Win_Kernel_Hook_Object.xsd | 109 + .../cybox/objects/Win_Kernel_Object.xsd | 128 + .../cybox/objects/Win_Mailslot_Object.xsd | 56 + .../objects/Win_Memory_Page_Region_Object.xsd | 198 ++ .../schema/cybox/objects/Win_Mutex_Object.xsd | 42 + .../Win_Network_Route_Entry_Object.xsd | 200 ++ .../objects/Win_Network_Share_Object.xsd | 205 ++ .../schema/cybox/objects/Win_Pipe_Object.xsd | 73 + .../cybox/objects/Win_Prefetch_Object.xsd | 113 + .../cybox/objects/Win_Process_Object.xsd | 167 + .../cybox/objects/Win_Registry_Key_Object.xsd | 290 ++ .../cybox/objects/Win_Semaphore_Object.xsd | 42 + .../cybox/objects/Win_Service_Object.xsd | 287 ++ .../cybox/objects/Win_System_Object.xsd | 126 + .../objects/Win_System_Restore_Object.xsd | 199 ++ .../schema/cybox/objects/Win_Task_Object.xsd | 755 ++++ .../cybox/objects/Win_Thread_Object.xsd | 146 + .../cybox/objects/Win_User_Account_Object.xsd | 73 + .../cybox/objects/Win_Volume_Object.xsd | 161 + .../objects/Win_Waitable_Timer_Object.xsd | 90 + .../cybox/objects/X509_Certificate_Object.xsd | 270 ++ stix_validator/schema/data_marking.xsd | 92 + stix_validator/schema/exploit_target.xsd | 223 ++ .../extensions/address/ciq_address_3.0.xsd | 27 + .../schema/extensions/address/readme.txt | 1 + .../extensions/attack_pattern/capec_2.5.xsd | 31 + .../extensions/identity/ciq_identity_3.0.xsd | 108 + .../schema/extensions/identity/readme.txt | 1 + .../schema/extensions/malware/maec_4.0.xsd | 32 + .../schema/extensions/malware/readme.txt | 3 + .../extensions/marking/simple_marking.xsd | 30 + .../schema/extensions/marking/tlp.xsd | 39 + .../extensions/structured_coa/generic.xsd | 46 + .../extensions/test_mechanism/generic.xsd | 46 + .../test_mechanism/open_ioc_2010.xsd | 32 + .../extensions/test_mechanism/oval_5.10.xsd | 37 + .../extensions/test_mechanism/snort.xsd | 36 + .../schema/extensions/test_mechanism/yara.xsd | 36 + .../extensions/vulnerability/cvrf_1.1.xsd | 33 + .../extensions/vulnerability/readme.txt | 1 + .../external/capec_2.5/ap_schema_v2.5.xsd | 2671 ++++++++++++++ .../schema/external/cvrf_1.1/common.xsd | 176 + .../external/cvrf_1.1/cpe-language_2.2a.xsd | 182 + .../schema/external/cvrf_1.1/cvrf.xsd | 487 +++ .../schema/external/cvrf_1.1/cvss-v2_0.9.xsd | 415 +++ .../schema/external/cvrf_1.1/dc.xsd | 118 + .../schema/external/cvrf_1.1/prod.xsd | 292 ++ .../external/cvrf_1.1/scap-core_0.9.xsd | 170 + .../schema/external/cvrf_1.1/vuln.xsd | 631 ++++ .../schema/external/cvrf_1.1/xml.xsd | 287 ++ .../external/oasis_ciq_3.0/CommonTypes.xsd | 104 + .../external/oasis_ciq_3.0/xAL-types.xsd | 511 +++ .../schema/external/oasis_ciq_3.0/xAL.xsd | 672 ++++ .../external/oasis_ciq_3.0/xNAL-types.xsd | 36 + .../schema/external/oasis_ciq_3.0/xNAL.xsd | 126 + .../external/oasis_ciq_3.0/xNL-types.xsd | 222 ++ .../schema/external/oasis_ciq_3.0/xNL.xsd | 284 ++ .../external/oasis_ciq_3.0/xPIL-types.xsd | 854 +++++ .../schema/external/oasis_ciq_3.0/xPIL.xsd | 1621 +++++++++ .../oasis_ciq_3.0/xlink-2003-12-31.xsd | 90 + .../schema/external/open_ioc_2010/ioc-TR.xsd | 25 + .../schema/external/open_ioc_2010/ioc.xsd | 105 + .../external/oval_5.10/oval-common-schema.xsd | 781 +++++ .../oval_5.10/oval-definitions-schema.xsd | 1608 +++++++++ .../oval_5.10/oval-variables-schema.xsd | 84 + .../oval_5.10/xmldsig-core-schema.xsd | 309 ++ stix_validator/schema/incident.xsd | 786 +++++ stix_validator/schema/indicator.xsd | 309 ++ stix_validator/schema/stix_common.xsd | 762 ++++ stix_validator/schema/stix_core.xsd | 217 ++ .../schema/stix_default_vocabularies.xsd | 1578 +++++++++ stix_validator/schema/test.xsd | 15 + stix_validator/schema/threat_actor.xsd | 173 + stix_validator/schema/ttp.xsd | 340 ++ stix_validator/sdv.py | 69 + stix_validator/validator.py | 154 + 143 files changed, 43429 insertions(+) create mode 100755 stix_validator/LICENSE.txt create mode 100644 stix_validator/README.md create mode 100644 stix_validator/__init__.py create mode 100755 stix_validator/schema/campaign.xsd create mode 100755 stix_validator/schema/course_of_action.xsd create mode 100755 stix_validator/schema/cybox/cybox_common.xsd create mode 100755 stix_validator/schema/cybox/cybox_core.xsd create mode 100755 stix_validator/schema/cybox/cybox_default_vocabularies.xsd create mode 100755 stix_validator/schema/cybox/extensions/platform/README.txt create mode 100755 stix_validator/schema/cybox/extensions/platform/cpe2.3.xsd create mode 100755 stix_validator/schema/cybox/objects/API_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Account_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Address_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Artifact_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Code_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Custom_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/DNS_Cache_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/DNS_Query_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/DNS_Record_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Device_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Disk_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Disk_Partition_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Email_Message_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/File_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/GUI_Dialogbox_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/GUI_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/GUI_Window_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/HTTP_Session_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Library_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Link_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Linux_Package_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Memory_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Mutex_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Network_Connection_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Network_Flow_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Network_Packet_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Network_Route_Entry_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Network_Route_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Network_Socket_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Network_Subnet_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/PDF_File_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Pipe_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Port_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Process_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Product_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Semaphore_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Socket_Address_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/System_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/URI_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Unix_File_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Unix_Network_Route_Entry_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Unix_Pipe_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Unix_Process_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Unix_User_Account_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Unix_Volume_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/User_Account_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/User_Session_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Volume_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Whois_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Computer_Account_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Critical_Section_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Driver_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Event_Log_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Event_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Executable_File_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_File_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Handle_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Kernel_Hook_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Kernel_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Mailslot_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Memory_Page_Region_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Mutex_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Network_Route_Entry_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Network_Share_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Pipe_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Prefetch_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Process_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Registry_Key_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Semaphore_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Service_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_System_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_System_Restore_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Task_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Thread_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_User_Account_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Volume_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/Win_Waitable_Timer_Object.xsd create mode 100755 stix_validator/schema/cybox/objects/X509_Certificate_Object.xsd create mode 100755 stix_validator/schema/data_marking.xsd create mode 100755 stix_validator/schema/exploit_target.xsd create mode 100755 stix_validator/schema/extensions/address/ciq_address_3.0.xsd create mode 100755 stix_validator/schema/extensions/address/readme.txt create mode 100755 stix_validator/schema/extensions/attack_pattern/capec_2.5.xsd create mode 100755 stix_validator/schema/extensions/identity/ciq_identity_3.0.xsd create mode 100755 stix_validator/schema/extensions/identity/readme.txt create mode 100755 stix_validator/schema/extensions/malware/maec_4.0.xsd create mode 100755 stix_validator/schema/extensions/malware/readme.txt create mode 100755 stix_validator/schema/extensions/marking/simple_marking.xsd create mode 100755 stix_validator/schema/extensions/marking/tlp.xsd create mode 100755 stix_validator/schema/extensions/structured_coa/generic.xsd create mode 100755 stix_validator/schema/extensions/test_mechanism/generic.xsd create mode 100755 stix_validator/schema/extensions/test_mechanism/open_ioc_2010.xsd create mode 100755 stix_validator/schema/extensions/test_mechanism/oval_5.10.xsd create mode 100755 stix_validator/schema/extensions/test_mechanism/snort.xsd create mode 100755 stix_validator/schema/extensions/test_mechanism/yara.xsd create mode 100755 stix_validator/schema/extensions/vulnerability/cvrf_1.1.xsd create mode 100755 stix_validator/schema/extensions/vulnerability/readme.txt create mode 100755 stix_validator/schema/external/capec_2.5/ap_schema_v2.5.xsd create mode 100755 stix_validator/schema/external/cvrf_1.1/common.xsd create mode 100755 stix_validator/schema/external/cvrf_1.1/cpe-language_2.2a.xsd create mode 100755 stix_validator/schema/external/cvrf_1.1/cvrf.xsd create mode 100755 stix_validator/schema/external/cvrf_1.1/cvss-v2_0.9.xsd create mode 100755 stix_validator/schema/external/cvrf_1.1/dc.xsd create mode 100755 stix_validator/schema/external/cvrf_1.1/prod.xsd create mode 100755 stix_validator/schema/external/cvrf_1.1/scap-core_0.9.xsd create mode 100755 stix_validator/schema/external/cvrf_1.1/vuln.xsd create mode 100755 stix_validator/schema/external/cvrf_1.1/xml.xsd create mode 100755 stix_validator/schema/external/oasis_ciq_3.0/CommonTypes.xsd create mode 100755 stix_validator/schema/external/oasis_ciq_3.0/xAL-types.xsd create mode 100755 stix_validator/schema/external/oasis_ciq_3.0/xAL.xsd create mode 100755 stix_validator/schema/external/oasis_ciq_3.0/xNAL-types.xsd create mode 100755 stix_validator/schema/external/oasis_ciq_3.0/xNAL.xsd create mode 100755 stix_validator/schema/external/oasis_ciq_3.0/xNL-types.xsd create mode 100755 stix_validator/schema/external/oasis_ciq_3.0/xNL.xsd create mode 100755 stix_validator/schema/external/oasis_ciq_3.0/xPIL-types.xsd create mode 100755 stix_validator/schema/external/oasis_ciq_3.0/xPIL.xsd create mode 100755 stix_validator/schema/external/oasis_ciq_3.0/xlink-2003-12-31.xsd create mode 100755 stix_validator/schema/external/open_ioc_2010/ioc-TR.xsd create mode 100755 stix_validator/schema/external/open_ioc_2010/ioc.xsd create mode 100755 stix_validator/schema/external/oval_5.10/oval-common-schema.xsd create mode 100755 stix_validator/schema/external/oval_5.10/oval-definitions-schema.xsd create mode 100755 stix_validator/schema/external/oval_5.10/oval-variables-schema.xsd create mode 100755 stix_validator/schema/external/oval_5.10/xmldsig-core-schema.xsd create mode 100755 stix_validator/schema/incident.xsd create mode 100755 stix_validator/schema/indicator.xsd create mode 100755 stix_validator/schema/stix_common.xsd create mode 100755 stix_validator/schema/stix_core.xsd create mode 100755 stix_validator/schema/stix_default_vocabularies.xsd create mode 100755 stix_validator/schema/test.xsd create mode 100755 stix_validator/schema/threat_actor.xsd create mode 100755 stix_validator/schema/ttp.xsd create mode 100755 stix_validator/sdv.py create mode 100755 stix_validator/validator.py diff --git a/stix_validator/LICENSE.txt b/stix_validator/LICENSE.txt new file mode 100755 index 0000000..1ee58c7 --- /dev/null +++ b/stix_validator/LICENSE.txt @@ -0,0 +1,24 @@ +Copyright (c) 2013, The MITRE Corporation +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are met: + * Redistributions of source code must retain the above copyright + notice, this list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in the + documentation and/or other materials provided with the distribution. + * Neither the name of The MITRE Corporation nor the + names of its contributors may be used to endorse or promote products + derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE +DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR +ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES +(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; +LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND +ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS +SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. diff --git a/stix_validator/README.md b/stix_validator/README.md new file mode 100644 index 0000000..e69de29 diff --git a/stix_validator/__init__.py b/stix_validator/__init__.py new file mode 100644 index 0000000..e69de29 diff --git a/stix_validator/schema/campaign.xsd b/stix_validator/schema/campaign.xsd new file mode 100755 index 0000000..b423998 --- /dev/null +++ b/stix_validator/schema/campaign.xsd @@ -0,0 +1,209 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Campaign + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) - Campaign - Schematic implementation for the Campaign construct within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + + The Campaign field characterizes a single cyber threat Campaign. + + + + + The CampaignType characterizes a single cyber threat Campaign. + + + + + + + The Title field provides a simple title for this Campaign. + + + + + The Names field specifies Names used to identify this Campaign. These may be either internal or external names. + + + + + + The Intended_Effect field characterizes the intended effect of this cyber threat Campaign. + + It is implemented through the StatementType, which allows for the expression of a statement in a vocabulary (Value), a description of the statement (Description), a confidence in the statement (Confidence), and the source of the statement (Source). The default vocabulary type for the Value is IntendedEffectVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The status of this Campaign. For example, is the Campaign ongoing, historical, future, etc. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is CampaignStatusType in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + The Related_TTPs field specifies TTPs asserted to be related to this cyber threat Campaign. + + + + + The Related_Incidents field identifies or characterizes one or more Incidents related to this cyber threat Campaign. + + + + + The Related_Indicators field identifies or characterizes one or more cyber threat Indicators related to this cyber threat Campaign. + + + + + The Attribution field specifies assertions of attibuted Threat Actors for this cyber threat Campaign. + + + + + The Associated_Campaigns field specifies other cyber threat Campaigns asserted to be associated with this cyber threat Campaign. + + + + + The Confidence field characterizes the level of confidence held in the characterization of this Campaign. + + + + + The Activity field characterizes actions taken in regards to this ThreatActor. This field is defined as of type ActivityType which is an abstract type enabling the extension and inclusion of various formats of Activity characterization. + + + + + The Information_Source field details the source of this entry. + + + + + The Handling field specifies the appropriate data handling markings for the elements of this Campaign. The valid marking scope is the nearest CampaignBaseType ancestor of this Handling element and all its descendants. + + + + + + Specifies the relevant STIX-Campaign schema version for this content. + + + + + + + + + An enumeration of all versions of the Campaign type valid in the current release of STIX. + + + + + + + + AttributionType specifies suspected Threat Actors attributed to a given Campaign. + + + + + + + The Attributed_Threat_Actor field specifies a Threat Actor asserted to be attributed for a Campaign. The specification of multiple ThreatActor entries for a single Attribution entry would be interpreted as a logical AND composition of the set of specified ThreatActors with a shared Confidence and Information Source. This would be used to assert attribution to a combined set of ThreatActors. + + + + + + + + + + + + + + + The Related_TTP field specifies a single TTP asserted to be related to this cyber threat Campaign. + + + + + + + + + + + + + The Name field specifies a Name used to identify this Campaign. This field can be used to capture various aliases used to identify this Campaign. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. No default vocabulary type has been defined for STIX 1.0. Users may either define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a free string field. + + + + + + + + + + + + + Identifies or characterizes an Incident related to this Campaign. + + + + + + + + + + + + + + The Related_Indicator field identifies or characterizes a cyber threat Indicator related to this Campaign. Such loose associations between Campaigns and Indicators are typically part of the early phases of Campaign identification and characterization. As the Campaign characterization matures these associations are often used to identify relevant TTPs and/or Incidents associated with the Campaign. + + + + + + + + + + + + + The Associated_Campaign field specifies a single other cyber threat Campaign asserted to be associated with this cyber threat Campaign. + + + + + + + diff --git a/stix_validator/schema/course_of_action.xsd b/stix_validator/schema/course_of_action.xsd new file mode 100755 index 0000000..df1b5d4 --- /dev/null +++ b/stix_validator/schema/course_of_action.xsd @@ -0,0 +1,165 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX COA + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) - COA - Schematic implementation for the CourseOfAction construct within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + The CourseOfAction field characterizes a Course of Action to be taken in regards to one of more cyber threats. NOTE: This construct is still in its early stages of maturity and will require a good deal of review and refinement. + + + + + The CourseOfActionType characterizes a Course of Action to be taken in regards to one of more cyber threats. NOTE: This construct is still in its early stages of maturity and will require a good deal of review and refinement. + + + + + + + The Title field provides a simple title for this CourseOfAction. + + + + + + The Stage field specifies what stage in the cyber threat management lifecycle this CourseOfAction is relevant to (e.g. Remedy or Reponse). + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is COAStageVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Type field specifies the type of this CourseOfAction. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. No default vocabulary type has been defined for STIX 1.0. Users may either define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a free string field. + + + + + + The Description element is optional and enables a generalized but structured description of this CourseOfAction. + + + + + The Objective field characterizes the objective of this CourseOfAction. + + + + + + The Structured_COA field enables the specification of an actionable structured representation for the CourseOfAction potentially for automated consumption and implementation. + + This field is implemented through the xsi:type extension mechanism. While STIX has not defined a default type, it has provided support for passing proprietary or externally defined structured courses of action using the Generic Structured COA extension. The Generic Structured COA extension is captured in the GenericStructuredCOAType in the http://stix.mitre.org/extensions/StructuredCOA#Generic-1 namespace. This type is defined in the extensions/structured_coa/generic.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/structured_coa/generic/1.0/generic.xsd. + + + + + + + The Impact field characterizes the estimated impact of applying this CourseOfAction. + + It is implemented through the StatementType, which allows for the expression of a statement in a vocabulary (Value), a description of the statement (Description), a confidence in the statement (Confidence), and the source of the statement (Source). The default vocabulary type for the Value is HighMediumLowVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Cost field characterizes the estimated cost for applying this CourseOfAction. + + It is implemented through the StatementType, which allows for the expression of a statement in a vocabulary (Value), a description of the statement (Description), a confidence in the statement (Confidence), and the source of the statement (Source). The default vocabulary type for the Value is HighMediumLowVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Efficacy field characterizes the effectiveness of this CourseOfAction in achieving its targeted Objective. + + It is implemented through the StatementType, which allows for the expression of a statement in a vocabulary (Value), a description of the statement (Description), a confidence in the statement (Confidence), and the source of the statement (Source). The default vocabulary type for the Value is HighMediumLowVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + The Handling field specifies the appropriate data handling markings for the elements of this COA. The valid marking scope is the nearest CourseOfActionBaseType ancestor of this Handling element and all its descendants. + + + + + + Specifies the relevant STIX-COA schema version for this content. + + + + + + + + + An enumeration of all versions of the Course of Action type valid in the current release of STIX. + + + + + + + + + The StructuredCOAType enables the specification of an actionable structured representation for the CourseOfAction potentially for automated consumption and implementation. + + This type is defined as an abstract type and is intended to be extended using the XML Schema extension mechanism to allow for the expression of a variety of structured COA types. Instance documents representing structured COAs use the xsi:type attribute to specify which implementation of this type they wish to use. + + STIX has provided one implementation to allow for the passing of proprietary or externally defined structured courses of action in a CDATA block. This implementation is captured in the Generic Structured COA extension, which provides the GenericStructuredCOAType in the http://stix.mitre.org/extensions/StructuredCOA#Generic-1 namespace. The extension is defined in the extensions/structured_coa/generic.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/structured_coa/generic/1.0/generic.xsd. + + + + + Specifies a unique ID for this StructuredCOA. + + + + + Specifies a reference to the ID for this StructuredCOA specified elsewhere. + + + + + + The ObjectiveType characterizes the objective of this CourseOfAction. + + + + + The Description element is optional and enables a generalized description of the objective of this CourseOfAction. + + + + + The Applicability_Confidence field characterizes the level of confidence held in the applicability of this suggested COA for its targeted Objective. + + + + + diff --git a/stix_validator/schema/cybox/cybox_common.xsd b/stix_validator/schema/cybox/cybox_common.xsd new file mode 100755 index 0000000..49da7c9 --- /dev/null +++ b/stix_validator/schema/cybox/cybox_common.xsd @@ -0,0 +1,2319 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + CybOX Common + 2.0 + 04/08/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Common Types. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + The MeasureSourceType is a type representing a description of a single cyber observation source. + + + + + The Information_Source_Type field is optional and utilizes a standardized controlled vocabulary to identify the type of information source leveraged for this cyber observation source. + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is InformationSourceTypeVocab in the http://cybox.mitre.org/default_vocabularies-2 namespace. This type is defined in the cybox_default_vocabularies.xsd file or at the URL http://cybox.mitre.org/XMLSchema/default_vocabularies/2.0/cybox_default_vocabularies.xsd. + Users may also define their own vocabulary using the type extension mechanism (by specifying a vocabulary name and/or reference using the vocab_name and vocab_reference attributes, respectively) or simply use this as a string field. + + + + + The Tool_Type field is optional and (when tools are used) enables identification of the type of tool leveraged as part of this cyber observation source, via a standardized controlled vocabulary. + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is ToolTypeVocab in the http://cybox.mitre.org/default_vocabularies-2 namespace. This type is defined in the cybox_default_vocabularies.xsd file or at the URL http://cybox.mitre.org/XMLSchema/default_vocabularies/2.0/cybox_default_vocabularies.xsd. + Users may also define their own vocabulary using the type extension mechanism (by specifying a vocabulary name and/or reference using the vocab_name and vocab_reference attributes, respectively) or simply use this as a string field. + + + + + The Description field is optional and enables a generalized but structured description of this syber observation source. + + + + + The Contributors field is optional and enables description of the individual contributors involved in this cyber observation source. + + + + + The Time field is optional and enables description of various time-related properties for this cyber observation source instance. + + + + + The Tools field is optional and enables description of the tools utilized for this cyber observation source. + + + + + The Platform field is optional and enables a formal, standardized specification of the platform for this cyber observation source. + + + + + The System field is optional and enables characterization of the system on which the mechanism of cyber observation executed. System should be an object of type SystemObj:SystemObjectType + + + + + The Instance field is optional and enables characterization of the process instance in which the mechanism of cyber observation executed. Instance should be of type ProcessObj:ProcessObjectType. + + + + + + The class field is optional and enables identification of the high-level class of this cyber observation source. + + + + + The source_type field is optional and enables identification of the broad type of this cyber observation source. + + + + + The name field is optional and enables the assignment of a relevant name to a this Discovery Method. + + + + + + The SourceClassTypeEnum is a (non-exhaustive) enumeration of cyber observation source classes. + + + + + Describes a Network-based cyber observation. + + + + + Describes a System-based cyber observation. + + + + + Describes a Software-based cyber observation. + + + + + + + The SourceTypeEnum is a (non-exhaustive) enumeration of cyber observation source types. + + + + + Describes a cyber observation made using various tools, such as scanners, firewalls, gateways, protection systems, and detection systems. See ToolTypeEnum for a more complete list of tools that CybOX supports. + + + + + Describes a cyber observation made from analysis methods, such as Static and Dynamic methods. See AnalysisMethodTypeEnum for a more complete list of methods that CybOX supports. + + + + + Describes a cyber observation made using other information sources, such as logs, Device Driver APIs, and TPM output data. See InformationSourceTypeEnum for a more complete list of information sources that CybOX supports. + + + + + + + The ContributorType represents a description of an individual who contributed as a source of cyber observation data. + + + + + This field describes the role played by this contributor. + + + + + This field contains the name of this contributor. + + + + + This field contains the email of this contributor. + + + + + This field contains a telephone number of this contributor. + + + + + This field contains the organization name of this contributor. + + + + + This field contains a description (bounding) of the timing of this contributor's involvement. + + + + + This field contains information describing the location at which the contributory activity occured. + + + + + + + The DateRangeType specifies a range of dates. + + + + + This field contains the start date for this contributor's involvement. + + + + + This field contains the end date for this contributor's involvement. + + + + + + + The PersonnelType is an abstracted data type to standardize the description of sets of personnel. + + + + + This field contains information describing the identify, resources and timing of involvement for a single contributor. + + + + + + + The TimeType specifies various time properties for a cyber observation source. + + + + + The Start_Time field is optional and describes the starting time for this cyber observation source instance. + + + + + The End_Time field is optional and describes the ending time for this cyber observation source instance. + + + + + The Produced_Time field is optional and describes the time that this cyber observation source instance was produced. + + + + + The Received_Time field is optional and describes the time that this cyber observation source instance was received. + + + + + + + The ToolSpecificDataType is an Abstract type placeholder within the CybOX schema enabling the inclusion of metadata for a specific type of tool through the use of a custom type defined as an extension of this base Abstract type. + + + + + The ToolsInformationType represents a description of a set of automated tools. + + + + + The Tool field is optional and enables description of a single tool utilized for this cyber observation source. + + + + + + + The ToolInformationType represens a description of a single automated tool. + + + + + This field contains the name of the tool leveraged. + + + + + + This field contains the type of the tool leveraged. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. No default vocabulary type has been defined for CybOX 2.0. Users may either define their own vocabulary using the type extension mechanism (by specifying a vocabulary name and/or reference using the vocab_name and vocab_reference attributes, respectively) or simply use this as a free string field. Additionally, locations where the ToolInformationType is used may define default vocabularies for this field. + + + + + + This field contains general descriptive information for this tool. + + + + + This field contains references to instances or additional information for this tool. + + + + + This field contains information identifying the vendor organization for this tool. + + + + + This field contains an appropriate version descriptor of this tool. + + + + + This field contains an appropriate service pack descriptor for this tool. + + + + + This is an abstract type provided to a flexible mechanism for enabling tool-specific data to be included. + + + + + This field contains a hash value computed on the tool file content in order to verify its integrity. + + + + + This field contains information describing the configuration and usage of the tool. + + + + + This field contains information describing the execution environment of the tool. + + + + + This field captures any errors generated during the run of the tool. + + + + + This field captures other relevant metadata including tool-specific fields. + + + + + + The id field specifies a unique ID for this Tool. + + + + + The idref field specifies reference to a unique ID for this Tool. + + + + + + Used to indicate one or more references to tool instances and information + + + + + Contains one reference to information or instances of a given tool + + + + + + + Contains one reference to information or instances of a given tool + + + + + + Indicates the nature of the referenced material (documentation, source, executable, etc.) + + + + + + + + The nature of referenced material regarding a tool + + + + + The reference is to documentation about the identified tool + + + + + The reference is to source code for the identified tool + + + + + The reference is to where an executable version of the tool can be downloaded + + + + + The reference is to the tool implemented as an online service. + + + + + The reference is to material about the tool not covered by other values in this enumeration. + + + + + + + The ToolConfigurationType characterizes the configuration for a tool used as a cyber observation source. + + + + + This field describes the configuration settings of this tool instance. + + + + + This field contains information describing the relevant dependencies for this tool. + + + + + This field contains descriptions of the various relevant usage context assumptions for this tool . + + + + + This field contains information describing relevant internationalization setting for this tool . + + + + + This field contains information describing how this tool was built. + + + + + + + The ConfigurationSettingsType is a modularized data type used to provide a consistent approach to describing configuration settings for a tool, application or other cyber object + + + + + This field contains a single configuration setting instance. + + + + + + + The ConfigurationSettingType is a modularized data type used to provide a consistent approach to describing a particular configuration setting for a tool, application or other cyber object + + + + + This field contains the name of the configuration item referenced by this configuration setting instance. + + + + + This field contains the value of this configuration setting instance. + + + + + This field contains the type of the configuration item referenced in this configuration setting instance. + + + + + This field contains a description of the configuration item referenced in this configuration setting instance. + + + + + + + The DependenciesType contains information describing a set of dependencies for this tool. + + + + + This field contains information describing a single dependency for this tool. + + + + + + + The DependencyType contains information describing a single dependency for this tool. + + + + + This field describes the type of this dependency instance. + + + + + This field contains a description of this dependency instance. + + + + + + + The UsageContextAssumptionsType contains descriptions of the various relevant usage context assumptions for this tool + + + + + This field contains a single usage context assumption for this tool. + + + + + + + The InternationalizationSettingsType contains information describing relevant internationalization setting for this tool + + + + + This field contains a single internal string instance for this internationalization setting instance. + + + + + + + The InternalStringsType contains a single internal string instance for this internationalization setting instance. + + + + + This field contains the actual key of this internal string instance. + + + + + This field contains the actual content of this internal string instance. + + + + + + + The BuildInformationType contains information describing how this tool was built. + + + + + This field contains an externally defined unique identifier of this build of this application instance. + + + + + This field contains the project name of this build of this application instance. + + + + + This field contains information identifying the utility used to build this application. + + + + + This field contains the appropriate version descriptor of this build of this application instance. + + + + + This field contains any relevant label for this build of this application instance. + + + + + This field describes the compilers utilized during this build of this application. + + + + + This field identifies the compilation date for the build of the tool. + + + + + This field describes how the build utility was configured for this build of this application. + + + + + This field contains the actual build script for this build of this application instance. + + + + + This field identifies the libraries incorporated into the build of the tool. + + + + + This field contains a capture of the output log of the build process. + + + + + + + The BuildUtilityType contains information identifying the utility used to build this application. + + + + + This field contains the informally defined name of the utility used to build this application instance. + + + + + This field identifies the build utility used to build this application. + + + + + + + The CompilersType describes the compilers utilized during this build of this application. + + + + + This field describes a single compiler utilized during this build of this application. + + + + + + + The CompilerType describes a single compiler utilized during this build of this application. + + + + + This field contains the informal description of this compiler instance. + + + + + This field identifies this compiler instance. + + + + + + + The CompilerInformalDescriptionType contains the informal description of this compiler instance. + + + + + This field contains the name of the compiler. + + + + + This field contains the version of the compiler. + + + + + + + The BuildConfigurationType describes how the build utility was configured for this build of this application. + + + + + This field contains the description of the configuration settings for this build of this application instance. + + + + + This field contains the configuration settings for this build of this application instance. + + + + + + + The LibrariesType identifies the libraries incorporated into the build of the tool. + + + + + This field identifies a library incorporated into the build of the tool. + + + + + + + The LibraryType identifies a single library incorporated into the build of the tool. + + + + This field identifies the name of the library. + + + + + This field identifies the version of the library. + + + + + + The ExecutionEnvironmentType contains information describing the execution environment of the tool. + + + + + This field contains information describing the system on which the tool was executed. System should be of type SystemObj:SystemObjectType. + + + + + This field contains information describing the user account that executed the tool. User_Account_Info should be of type UserAccountObj:UserAccountObjectType. + + + + + This field specifies the command line string used to run the tool. + + + + + Thie field specifies when the tool was run. + + + + + + + The ErrorsType captures any errors generated during the run of the tool. + + + + + This field captures a single type of error generated during the run of the tool. + + + + + + + The ErrorType captures a single error generated during the run of the tool. + + + + + This field specifies the the type for this tool run error. + + + + + This field specifies the count of instances for this error in the tool run. + + + + + This field captures the actual error output for each instance of this type of error. + + + + + + + The ErrorInstancesType captures the actual error output for each instance of this type of error. + + + + + This field captures the actual error output for a single instance of this type of error. + + + + + + + + The ObjectPropertiesType is an Abstract type placeholder within the CybOX schema enabling the inclusion of contextually varying object properties descriptions. This Abstract type is leveraged as the extension base for all predefined CybOX object properties schemas. Through this extension mechanism any object instance data based on an object properties schema extended from ObjectPropertiesType (e.g. File_Object, Address_Object, etc.) can be directly integrated into any instance document where a field is defined as ObjectPropertiesType. For flexibility and extensibility purposes any user of CybOX can specify their own externally defined object properties schemas (outside of or derived from the set of predefined objects) extended from ObjectPropertiesType and utilize them as part of their CybOX content. + + + + + The Custom_Properties construct is optional and enables the specification of a set of custom Object Properties that may not be defined in existing Properties schemas. + + + + + + The object_reference field specifies a unique ID reference to an Object defined elsewhere. This construct allows for the re-use of the defined Properties of one Object within another, without the need to embed the full Object in the location from which it is being referenced. Thus, this ID reference is intended to resolve to the Properties of the Object that it points to. + + + + + + The CustomPropertiesType enables the specification of a set of custom Object Properties that may not be defined in existing Properties schemas. + + + + + The Property construct enables the specification of a single Object Property. + + + + + + + The PropertyType is a type representing the specification of a single Object Property. + + + + + + The name field specifies a name for this property. + + + + + A description of what this property represents. + + + + + + + + + The BaseObjectPropertyType is a type representing a common typing foundation for the specification of a single Object Property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + + + The IntegerObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type Int. This type will be assigned to any property of a CybOX object that should contain content of type Integer and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The StringObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type String. This type will be assigned to any property of a CybOX object that should contain content of type String and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The NameObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type Name. This type will be assigned to any property of a CybOX object that should contain content of type Name and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The DateObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type Date. This type will be assigned to any property of a CybOX object that should contain content of type Date and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The DateTimeObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type DateTime. This type will be assigned to any property of a CybOX object that should contain content of type DateTime and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The FloatObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type Float. This type will be assigned to any property of a CybOX object that should contain content of type Float and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The DoubleObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type Double. This type will be assigned to any property of a CybOX object that should contain content of type Double and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The UnsignedLongObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type UnsignedLong. This type will be assigned to any property of a CybOX object that should contain content of type UnsignedLong and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The UnsignedIntegerObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type UnsignedInt. This type will be assigned to any property of a CybOX object that should contain content of type UnsignedInteger and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The PositiveIntegerObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type PositveInteger. This type will be assigned to any property of a CybOX object that should contain content of type PositiveInteger and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The HexBinaryObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type HexBinary. This type will be assigned to any property of a CybOX object that should contain content of type HexBinary and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The LongObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type Long. This type will be assigned to any property of a CybOX object that should contain content of type Long and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The NonNegativeIntegerObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type nonNegativeInteger. This type will be assigned to any property of a CybOX object that should contain content of type NonNegativeInteger and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The AnyURIObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type anyURI. This type will be assigned to any property of a CybOX object that should contain content of type AnyURI and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The DurationObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type duration. This type will be assigned to any property of a CybOX object that should contain content of type Duration and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The TimeObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type time. This type will be assigned to any property of a CybOX object that should contain content of type Time and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The Base64BinaryObjectPropertyType is a type (extended from BaseObjectPropertyType) representing the specification of a single Object property whose core value is of type base64Binary. This type will be assigned to any property of a CybOX object that should contain content of type Base64Binary and enables the use of relevant metadata for the property. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The ObjectPropertyGroup is a simple field group aggregating a set of fields for Object Properties. + + + + The id field specifies a unique ID for this Object Property. + + + + + The idref field specifies a unique ID reference for this Object Property. + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + This field is optional and conveys whether the associated object property value appears to somewhat random in nature. An object property with this field set to TRUE need not provide any further information including a value. If more is known about the particular variation of randomness, a regex value could be provided to outline what is known of the structure. + + + + + This field is optional and conveys whether the associated Object property has been obfuscated. + + + + + This field is optional and conveys a reference to a description of the algorithm used to obfuscate this Object property. + + + + + This field is optional and conveys whether the associated Object property has been defanged (representation changed to prevent malicious effects of handling/processing). + + + + + This field is optional and conveys a reference to a description of the algorithm used to defang (representation changed to prevent malicious effects of handling/processing) this Object property. + + + + + This field is optional and specifies the type (e.g. RegEx) of refanging transform specified in the optional accompanying refangingTransform property. + + + + + This field is optional and specifies an automated transform that can be applied to the Object property content in order to refang it to its original format. + + + + + + The PatternFieldGroup is a simple field group aggregating a set of fields for application of patterns. + + + + This field is optional and defines the relevant condition to apply to the value. + + + + + This field indicates how a condition should be applied when the field body contains a list of values. (Its value is moot if the field value contains only a single value - both possible values for this field would have the same behavior.) If this field is set to ANY, then a pattern is considered to be matched if the provided condition successfully evaluates for any of the values in the field body. If the field is set to ALL, then the patern only matches if the provided condition successfully evaluates for every value in the field body. + + + + + Used to specify a bit_mask in conjunction with one of the defined binary conditions (bitwiseAnd, bitwiseOr, and bitwiseXor). This bitmask is then uses as one operand in the indicated bitwise computation. + + + + + This field is optional and defines the type of pattern used if one is specified for the field value. This is applicable only if the Condition field is set to 'FitsPattern'. + + + + + This field is optional and defines the syntax format used for a regular expression, if one is specified for the field value. This is applicable only if the Condition field is set to 'FitsPattern'. + + Setting this attribute with an empty value (e.g., "") or omitting it entirely notifies CybOX consumers and pattern evaluators that the corresponding regular expression utilizes capabilities, character classes, escapes, and other lexical tokens defined by the CybOX Language Specification. + + Setting this attribute with a non-empty value notifies CybOX consumers and pattern evaluators that the corresponding regular expression utilizes capabilities not definied by the CybOX Language Specification. The regular expression must be evaluated through a compatible regular expression engine in this case. + + + + + + This field is optional and conveys a targeted observation pattern of whether the associated field value has changed. This field would be leveraged within a pattern observable triggering on whether the value of a single field value has changed. + + + + + This field is optional and conveys a targeted observation pattern of the nature of any trend in the associated field value. This field would be leveraged within a pattern observable triggering on the matching of a specified trend in the value of a single specified field. + + + + + + ConditionTypeEnum is a (non-exhaustive) enumeration of condition types. + + + + + Specifies the equality or = condition. + + + + + Specifies the "does not equal" or != condition. + + + + + Specifies the "contains" condition. + + + + + Specifies the "does not contain" condition. + + + + + Specifies the "starts with" condition. + + + + + Specifies the "ends with" condition. + + + + + Specifies the "greater than" condition. + + + + + Specifies the "greater than or equal to" condition. + + + + + Specifies the "less than" condition. + + + + + Specifies the "less than or equal" condition. + + + + + The pattern is met if the given value lies between the values indicated in the field value body, inclusive of the bounding values themselves. The field value body MUST contain at least 2 values to be valid. If the field value body contains more than 2 values, then only the greatest and least values are considered. (I.e., If the body contains "2,4,6", then an InclusiveBetween condition would be satisfied if the observed value fell between 2 and 6, inclusive. Since this is an inclusive range, an observed value of 2 or 6 would fit the pattern in this example.) As such, always treat the InclusiveBetween condition as applying to a single range for the purpose of evaluating the apply_condition attribute. + + + + + The pattern is met if the given value lies between the values indicated in the field value body, exclusive of the bounding values themselves. The field value body MUST contain at least 2 values to be valid. If the field value body contains more than 2 values, then only the greatest and least values are considered. (I.e., If the body contains "2,4,6", then an InclusiveBetween condition would be satisfied if the observed value fell between 2 and 6, exclusive. Since this is an exclusive range, an observed value of 2 or 6 would not fit the pattern in this example.) As such, always treat the ExclusiveBetween condition as applying to a single range for the purpose of evaluating the apply_condition attribute. + + + + + Specifies the condition that a value fits a given pattern. + + + + + Specifies the condition of bitwise AND. Specifically, when applying this pattern, a given value is bitwise-ANDed with the bit_mask attribute value (which must be present). If the result is identical to the value provided in the body of this field value, the pattern is considered fulfilled. + + + + + Specifies the condition of bitwise OR. Specifically, when applying this pattern, a given value is bitwise-ORed with the bit_mask attribute value (which must be present). If the result is identical to the value provided in the body of this field value, the pattern is considered fulfilled. + + + + + Specifies the condition of bitwise XOR. Specifically, when applying this pattern, a given value is bitwise-XORed with the bit_mask attribute value (which must be present). If the result is identical to the value provided in the body of this field value, the pattern is considered fulfilled. + + + + + + + Used to indicate how a condition should be applied to a list of values. + + + + + Indicates that a pattern holds if the given condition can be successfully applied to any of the field values. + + + + + Indicates that a pattern holds only if the given condition can be successfully applied to all of the field values. + + + + + Indicates that a pattern holds only if the given condition can be successfully applied to none of the field values. + + + + + + + DataTypeEnum is a (non-exhaustive) enumeration of data types. + + + + + Specifies the string datatype as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#string for more information. + + + + + Specifies the int datatype as it applies to the W3C standard for int. See http://www.w3.org/TR/xmlschema-2/#int for more information. + + + + + Specifies the float datatype as it apples to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#float for more information. + + + + + Specifies a date, which is usually in the form yyyy-mm--dd as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#date for more information. + + + + + Specifies a positive integer in the infinite set {1,2,...} as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#positiveInteger for more information. + + + + + Specifies an unsigned integer, which is a nonnegative integer in the set {0,1,2,...,4294967295} as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#unsignedInt for more information. + + + + + Specifies a date in full format including both date and time as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#dateTime for more information. + + + + + Specifies a time as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#time for more information. + + + + + Specifies a boolean value in the set {true,false,1,0} as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#boolean for more information. + + + + + Specifies a name (which represents XML Names) as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#Name and http://www.w3.org/TR/2000/WD-xml-2e-20000814#dt-name for more information. + + + + + Specifies a long integer, which is an integer whose maximum value is 9223372036854775807 and minimum value is -9223372036854775808 as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#long for more information. + + + + + Specifies an unsigned long integer, which is an integer whose maximum value is 18446744073709551615 and minimum value is 0 as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#unsignedLong for more information. + + + + + Specifies a length of time in the extended format PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds, as it applies to the W3 standard. See http://www.w3.org/TR/xmlschema-2/#duration for more information. + + + + + Specifies a decimal of datatype double as it is patterned after the IEEE double-precision 64-bit floating point type (IEEE 754-1985) and as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#double for more information. + + + + + Specifies a non-negative integer in the infinite set {0,1,2,...} as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#nonNegativeInteger for more information. + + + + + Specifies arbitrary hex-encoded binary data as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#hexBinary for more information. + + + + + Specifies a Uniform Resource Identifier Reference (URI) as it applies to the W3C standard and to RFC 2396, as amended by RFC 2732. See http://www.w3.org/TR/xmlschema-2/#anyURI for more information. + + + + + Specifies base64-encoded arbitrary binary data as it applies to the W3C standard. See http://www.w3.org/TR/xmlschema-2/#base64Binary for more information. + + + + + Specifies an IPV4 address in dotted decimal form. CIDR notation is also accepted. + + + + + Specifies an IPV6 address, which is represented by eight groups of 16-bit hexadecimal values separated by colons (:) in the form a:b:c:d:e:f:g:h. CIDR notation is also accepted. + + + + + Specifies a host name. For compatability reasons, this could be any string. Even so, it is best to use the proper notation for the given host type. For example, web hostnames should be written as fully qualified hostnames in practice. + + + + + Specifies a MAC address, which is represented by six groups of 2 hexdecimal digits, separated by hyphens (-) or colons (:) in transmission order. + + + + + Specifies a domain name, which is represented by a series of labels concatenated with dots comforming to the rules in RFC 1035, RFC 1123, and RFC 2181. + + + + + Specifies a Uniform Resource Identifier, which identifies a name or resource and can act as a URL or URN. + + + + + Specifies a timezone in UTC notation (UTC+number). + + + + + Specifies arbitrary octal (base-8) encoded data. + + + + + Specifies arbitrary binary encoded data. + + + + + Specifies arbitrary data encoded in the Mac OS-originated BinHex format. + + + + + Specifies a subnet mask in IPv4 or IPv6 notation. + + + + + Specifies a globally/universally unique ID represented as a 32-character hexadecimal string. See ISO/IEC 11578:1996 Information technology -- Open Systems Interconnection -- Remote Procedure Call - http://www.iso.ch/cate/d2229.html + + + + + Specifies data represented as a container of multiple data of a shared elemental type. + + + + + Specifies a CVE ID, expressed as CVE- appended by a four-digit integer, a - and another four-digit integer, as in CVE-2012-1234. + + + + + Specifies a CWE ID, expressed as CWE- appended by an integer. + + + + + Specifies a CAPEC ID, expressed as CAPEC- appended by an integer. + + + + + Specifies a CCE ID, expressed as CCE- appended by an integer. + + + + + Specifies a CPE Name. See http://cpe.mitre.org/specification/archive/version2.0/cpe-specification_2.0.pdf for more information. + + + + + + + The PatternTypeEnum type is a non-exhaustive enumeration of potentially relevant pattern types. + + + + + Specifies the regular expression pattern type. + + + + + Specifies the binary (bit operations) pattern type. + + + + + Specifies the XPath 1.0 expression pattern type. + + + + + + + + The ExtractedFeaturesType is a type representing a description of features extracted from an object such as a file. + + + + + This field enables description of a set of static strings extracted from a raw cyber object. + + + + + This field enables description of a set of references to external resources imported by a raw cyber object. + + + + + This field enables description of a set of references to functions called by a raw cyber object. + + + + + This field enables description of a set of code snippets extracted from a raw cyber object. + + + + + + + The ExtractedStringsType type is intended as container for strings extracted from CybOX objects. + + + + + This field enables description of a single static string extracted from a raw cyber object. + + + + + + + The ExtractedStringType type is intended as container a single string extracted from a CybOX object. + + + + + The Encoding field refers to the encoding method used for the string extracted from the CybOX object, via a standardized controlled vocabulary. + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is CharacterEncodingVocab in the http://cybox.mitre.org/default_vocabularies-2 namespace. This type is defined in the cybox_default_vocabularies.xsd file or at the URL http://cybox.mitre.org/XMLSchema/default_vocabularies/2.0/cybox_default_vocabularies.xsd. + Users may also define their own vocabulary using the type extension mechanism (by specifying a vocabulary name and/or reference using the vocab_name and vocab_reference attributes, respectively) or simply use this as a string field. + + + + + The String_Value field specifies the actual value of the string extracted from the CybOX object, if it is capable of being represented in the encoding scheme used in the document (most commonly UTF-8). + + + + + The Byte_String_Value field specifies the raw, byte-string representation of the string extracted from the CybOX object, in hexadecimal format. + + + + + The Hashes field is used to include any hash values computed using the string extracted from the CybOX object as input. + + + + + The Address field specifies the location or offset of the specified string in the CybOX objects. + + + + + The Length field specifies the length, in characters, of the string extracted from the CybOX object. + + + + + The Language field specifies the language the string is written in, e.g. English. + + + + + The English_Translation field specifies the English translation of the string, if it is not written in English. + + + + + + + The ImportsType is intended to represent an extracted list of imports specified within a CybOX object. + + + + + This field enables description of a single reference to an external resource imported by a raw cyber object. + + + + + + + The FunctionsType is intended to represent an extracted list of functions leveraged within a CybOX object. + + + + + This field enables description of a single reference to a function called by a raw cyber object. + + + + + + + The CodeSnippetsType is intended to represent an set of code snippets extracted from within a CybOX object. + + + + + This field enables description of a single code snippet extracted from a raw cyber object. Code_Snippet should be of CodeObj:CodeObjectType. + + + + + + + + The ByteRunsType is used for representing a list of byte runs from within a raw object. + + + + + The Byte_Run field contains a single byte run from the raw object. + + + + + + + The ByteRunType is used for representing a single byte run from within a raw object. + + + + + The Offset field specifies the offset of the beginning of the byte run as measured from the beginning of the object. + + + + + The File_System_Offset field is relevant only for byte runs of files in forensic analysis.It specifies the offset of the beginning of the byte run as measured from the beginning of the relevant file system. + + + + + The Image_Offset field is provided for forensic analysis purposes and specifies the offset of the beginning of the byte run as measured from the beginning of the relevant forensic image. + + + + + The Length field specifies the number of bytes in the byte run. + + + + + The Hashes field contains computed hash values for this the data in this byte run. + + + + + The Byte_Run_Data field contains a raw dump of the byte run data, typically enclosed within an XML CDATA section. + + + + + + + + The HashListType type is used for representing a list of hash values. + + + + + The Hash field specifies a single calculated hash value. + + + + + + + The HashValueType is used for specifying the resulting value from a hash calculation. + + + + + The Simple_Hash_Value field specifies a single result value of a basic cryptograhic hash function outputing a single hexbinary hash value. + + + + + The Fuzzy_Hash_Value field specifies a single result value of a cryptograhic fuzzy hash function outputing a single complex string based hash value. (e.g. SSDEEP's Block1hash:Block2hash format). + + + + + + + The SimpleHashValueType is used for characterizing the output of basic cryptograhic hash functions outputing a single hexbinary hash value. + + + + + + + + The FuzzyHashValueType is used for characterizing the output of cryptograhic fuzzy hash functions outputing a single complex string based hash value. + + + + + + + + The FuzzyHashStructureType is used for characterizing the internal components of a cryptograhic fuzzy hash algorithmic calculation. + + + + + The Block_Size field is optional and specifies the calculated block size for this fuzzy hash calculation. + + + + + The Block_Hash field is optional and enables specification of the elemental components utilized for a fuzzy hash calcuation on the hashed object utilizing Block_Size to calculate trigger points. + + + + + + + The FuzzyHashBlockType is used for characterizing the internal components of a single block in a cryptograhic fuzzy hash algorithmic calculation. + + + + + The Block_Hash_Value field is optional and specifies a fuzzy hash calculation result value for this Block. + + + + + The Segment_Count field is optional and specifies the number of segments identified and utlized within this fuzzy hash calculation. + + + + + The Segments field is optional and specifies the set of segments identified and utlized within this fuzzy hash calculation. + + + + + + + The HashSegmentsType is used for characterizing the internal components of a set of trigger point-delimited segments in a cryptograhic fuzzy hash algorithmic calculation. + + + + + The Segment field is optional and specifies a single segment identified and utlized within this fuzzy hash calculation. + + + + + + + The HashSegmentType is used for characterizing the internal components of a single trigger point-delimited segment in a cryptograhic fuzzy hash algorithmic calculation. + + + + + The Trigger_point field is optional and specifies the offset within the hashed object of the trigger point for this segment. + + + + + The Segment_Hash field is optional and specifies a calculated hash value for this segment. + + + + + The Raw_Segment_Content field is optional and contains the raw content of this segment of the hashed object. + + + + + + + The HashType type is intended to characterize hash values. + + + + + The Type field utilizes a standardized controlled vocabulary to capture the type of hash used in the Simple_Hash_Value or Fuzzy_Hash_Value elements. + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is HashNameVocab in the http://cybox.mitre.org/default_vocabularies-2 namespace. This type is defined in the cybox_default_vocabularies.xsd file or at the URL http://cybox.mitre.org/XMLSchema/default_vocabularies/2.0/cybox_default_vocabularies.xsd. + Users may also define their own vocabulary using the type extension mechanism (by specifying a vocabulary name and/or reference using the vocab_name and vocab_reference attributes, respectively) or simply use this as a string field. + + + + + + The Simple_Hash_Value field specifies a single result value of a basic cryptograhic hash function outputing a single hexbinary hash value. + + + + + The Fuzzy_Hash_Value field specifies a single result value of a cryptograhic fuzzy hash function outputing a single complex string based hash value. (e.g. SSDEEP's Block1hash:Block2hash format). + + + + + + The Fuzzy_Hash_Structure field is optional and enables the characterization of the key internal components of a fuzzy hash calculation with a given block size. + + + + + + + + The StructuredTextType is a type representing a generalized structure for capturing structured or unstructured textual information such as descriptions of things. + + + + + + Used to indicate a particular structuring format (e.g., HTML5) used within an instance of StructuredTextType. Note that if the markup tags used by this format would be interpreted as XML information (such as the bracket-based tags of HTML) the text area should be enclosed in a CDATA section to prevent the markup from interferring with XML validation of the CybOX document. If this attribute is absent, the implication is that no markup is being used. + + + + + + + + The ReferencesListType contains one or more Reference elements, each of which provide further reading and insight into the item. This should be filled out as appropriate. + + + + + Each Reference subelement should provide a single source from which more information and deeper insight can be obtained, such as a research paper or an excerpt from a publication. Multiple Reference subelements can exist. The sole component of this field is the id. The id is optional and translates to a preceding footnote below the context notes if the author of the entry wants to cite a reference. Not all subelements need to be completed, since some are designed for web references and others are designed for book references. The fields Reference_Author and Reference_Title should be filled out for all references if possible. Reference_Section and Reference_Date can be included for either book references or online references. Reference_Edition, Reference_Publication, Reference_Publisher, and Reference_PubDate are intended for book references, however they can be included where appropriate for other types of references. Reference_Link is intended for web references, however it can be included for book references as well if applicable. + + + + + + + The ReferenceType is a type representing a single reference to a source of information. + + + + + This field provides a description of the reference. + + + + + This field identifies an individual author of the material being referenced. It is not required, but may be repeated sequentially in order to identify multiple authors for a single piece of material. + + + + + This field identifies the title of the material being referenced. It is not required if the material does not have a title. + + + + + This field is intended to provide a means of identifying the exact location of the material inside of the publication source, such as the relevant pages of a research paper, the appropriate chapters from a book, etc. This is useful for both book references and internet references. + + + + + This field identifies the edition of the material being referenced in the event that multiple editions of the material exist. This will usually only be useful for book references. + + + + + This field identifies the publication source of the reference material, if one exists. + + + + + This field identifies the publisher of the reference material, if one exists. + + + + + This field identifies the date when the reference was included in the entry. This provides the reader with a time line for when the material in the reference, usually the link, was valid. The date should be of the format YYYY-MM-DD. + + + + + This field describes the date when the reference was published YYYY. + + + + + This field should hold the URL for the material being referenced, if one exists. This should always be used for web references, and may optionally be used for book and other publication references. + + + + + + The id field is optional and is used as a mechanism for citing text in the entry. If an id is provided, it is placed between brackets and precedes this reference and the matching id should be used inside of the text for the entry itself where this reference is applicable. All reference ids assigned within an entry must be unique. + + + + + + + The DataSegmentType is intended to provide a relatively abstract way of characterizing data segments that may be written/read/transmitted or otherwise utilized in actions or behaviors. + + + + + The Data_Format field refers to the type of data contained in the Data_Segment element. + + + + + The Data_Size field contains the size of the data contained in this element. + + + + + The Data_Segment field contains the actual segment of data being characterized. + + + + + The Offset field allows for the specification of where to start searching for the specified data segment in an object, in bytes. + + + + + The Search_Distance field specifies how far into an object should be ignored, in bytes, before starting to search for the specified data segment relative to the end of the previous data segment. + + + + + The Search_Within field specifies that at most N bytes are between data segments in related objects. + + + + + + The id field specifies a unique id for this data segment. + + + + + + The DataFormatEnum is a (non-exhaustive) enumeration of data formats. + + + + + Specifies binary data. + + + + + Specifies hexadecimal data. + + + + + Specifies text. + + + + + Specifies any other type of data from the ones listed. + + + + + + + The DataSizeType specifies the size of the data segment. + + + + + + This field represents the Units used in the object size element. Possible values are: Bytes, Kilobytes, Megabytes. + + + + + + + + The DataSizeUnitsEnum is a (non-exhaustive) enumeration of data size units. + + + + + Specifies an object size in Bytes. + + + + + Specifies an object size in Kilobytes. + + + + + Specifies an object size in Megabytes. + + + + + + + + PlatformSpecificationType is a modularized data type intended for providing a consistent approach to uniquely specifying the identity of a specific platform. + In addition to capturing basic information, this type is intended to be extended to enable the structured description of a platform instance using the XML Schema extension feature. The CybOX default extension uses the Common Platform Enumeration (CPE) Applicability Language schema to do so. The extension that defines this is captured in the CPE23PlatformSpecificationType in the http://cybox.mitre.org/extensions/platform#CPE2.3-1 namespace. This type is defined in the extensions/platform/cpe2.3.xsd file. + + + + + A prose description of the indicated platform. + + + + + Indicates a pre-defined name for the given platform using some naming scheme. For example, one could provide a CPE (Common Platform Enumeration) name using the CPE naming format. + + + + + + + Used to specify a name for a platform using a particular naming system and also allowing a reference pointing to more information about that naming scheme. For example, one could provide a CPE (Common Platform Enumeration) name using the CPE naming format. In this case, the system value could be "CPE" while the system_ref value could be "http://scap.nist.gov/specifications/cpe/". + + + + + + Indicates the naming system from which the indicated name was drawn. + + + + + A reference to information about the naming system from which the indicated name was drawn. + + + + + + + + + The MetadataType is intended as mechanism to capture any non-context-specific metadata + + + + + This field specifies the value of name of a single metadata field. + + + + + This field uses recursion of the MetadataType specify subdatum structures for this metadata field. + + + + + + This field specifies the type of name of a single metadata field. + + + + + + + The EnvironmentVariableListType type is used for representing a list of environment variables. + + + + + The Environment_Variable field is used for representing environment variables using a name/value pair. + + + + + + + The EnvironmentVariableType type is used for representing environment variables using a name/value pair. + + + + + The Name field specifies the name of the environment variable. + + + + + The Value field specifies the value of the environment variable. + + + + + + + + The DigitalSignaturesType is used for representing a list of digital signatures. + + + + + The Digital_Signature field is optional and captures a single digital signature for this Object. + + + + + + + The DigitalSignatureInfoType type is used as a way to represent some of the basic information about a digital signature. + + + + + The certificate issuer of the digital signature. + + + + + The certificate subject of the digital signature. + + + + + A description of the digital signature. + + + + + + Specifies whether the digital signature exists. + + + + + Specifies if the digital signature is verified. + + + + + + + The PatternableFieldType is a grouping of attributes applicable to defining patterns on a specific field. + + + + + + + + + + + The ControlledVocabularyStringType is used as the basis for defining controlled vocabularies. + + + + + + The vocab_name field specifies the name of the controlled vocabulary. + + + + + The vocab_reference field specifies the URI to the location of where the controlled vocabulary is defined, e.g., in an externally located XML schema file. + + + + + + + + + SIDType specifies Windows Security ID (SID) types via a union of the SIDTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + Properties that use this type can express multiple values by providing them using a comma separated list. As such, a comma is a reserved character in all uses of this type. Commas in values should be expressed as &comma; (that is, ampersand-"comma"-semicolon). Such expressions should be converted back to a comma before displaying to users or handing off values to tools for processing. Note that whitespace is preserved and so, when specifying a list of values, do not include a space following a comma in a list unless the first character of the next list item should, in fact, be a space. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The SIDTypeEnum type is an enumeration of Windows Security ID (SID) types. These correspond to the values specified by the SID_NAME_USE enumeration--see http://msdn.microsoft.com/en-us/library/windows/desktop/aa379601(v=vs.85).aspx for more information. + + + + + Indicates a SID of type User. + + + + + Indicates a SID of type Group. + + + + + Indicates a SID of type Domain. + + + + + Indicates a SID of type Alias. + + + + + Indicates a SID for a well-known group. + + + + + Indicates a SID for a deleted account. + + + + + Indicates an invalid SID. + + + + + Indicates a SID of unknown type. + + + + + Indicates a SID for a computer. + + + + + Indicates a mandatory integrity label SID. + + + + + diff --git a/stix_validator/schema/cybox/cybox_core.xsd b/stix_validator/schema/cybox/cybox_core.xsd new file mode 100755 index 0000000..3328acf --- /dev/null +++ b/stix_validator/schema/cybox/cybox_core.xsd @@ -0,0 +1,1090 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + CybOX Core + 2.0 + 04/08/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Core. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Observables construct represents a collection of cyber observables. + + + + + The ObservablesType is a type representing a collection of cyber observables. + + + + + The Observable_Package_Source field is optional and enables descriptive specification of how this package of Observables was identified and specified. + + + + + + The Pools construct enables the description of Events, Actions, Objects and Properties in a space-efficient pooled manner with the actual Observable structures defined in the CybOX schema containing references to the pooled elements. This reduces redundancy caused when identical observable elements occur multiple times within a set of defined Observables. + + + + + + The major_version field specifies the major version of the CybOX language utlized for this set of Observables. + + + + + The minor_version field specifies the minor version of the CybOX language utlized for this set of Observables. + + + + + + The Observable construct represents a description of a single cyber observable. + + + + + The ObservableType is a type representing a description of a single cyber observable. + + + + + The Title field provides a mechanism to specify a short title or description for this Observable + + + + + The Description field provides a mechanism to specify a structured text description of this Observable. + + + + + Keywords enables capture of relevant keywords for this cyber observable. + + + + + The Observable_Source field is optional and enables descriptive specification of how this Observable was identified and specified. + + + + + + The Object construct identifies and specificies the characteristics of a specific cyber-relevant object (e.g. a file, a registry key or a process). + + + + + The Event construct enables specification of a cyber observable event that is dynamic in nature with specific action(s) taken against specific cyber relevant objects (e.g. a file is deleted, a registry key is created or an HTTP Get Request is received). + + + + + The Observable_Composition construct enables specification of composite observables made up of logical constructions of atomic observables or other composite observables (e.g. Obs5 = (Obs1 OR Obs2) AND (Obs3 OR Obs4)). + + + + + + Pattern_Fidelity contains elements that enable the characterization of the fidelity of this pattern to its purpose. + + + + + + The id field specifies a unique id for this Observable. + + + + + The idref field specifies a unique id reference to an Observable defined elsewhere. + + + + + The negate field, when set to true, indicates the absence (rather than the presence) of the given Observable in a CybOX pattern. + + + + + + + TrendEnum is a (non-exhaustive) enumeration of trend types. + + + + + Specifies an increasing trend. + + + + + Specifies a decreasing trend. + + + + + + + + The Event construct enables specification of a cyber observable event that is dynamic in nature with specific action(s) taken against specific cyber relevant objects (e.g. a file is deleted, a registry key is created or an HTTP Get Request is received). + + + + + The EventType is a complex type representing a cyber observable event that is dynamic in nature with specific action(s) taken against specific cyber relevant objects (e.g. a file is deleted, a registry key is created or an HTTP Get Request is received). + + + + + + The Type field uses a standardized controlled vocabulary to capture what type of Event this is. + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is EventTypeVocab in the http://cybox.mitre.org/default_vocabularies-2 namespace. This type is defined in the cybox_default_vocabularies.xsd file or at the URL http://cybox.mitre.org/XMLSchema/default_vocabularies/2.0/cybox_default_vocabularies.xsd. + Users may also define their own vocabulary using the type extension mechanism (by specifying a vocabulary name and/or reference using the vocab_name and vocab_reference attributes, respectively) or simply use this as a string field. + + + + + The Description field provides a mechanism to specify a structured text description of this Event. + + + + + The Observation_Method field is optional and enables descriptive specification of how this Event was observed (in the case of a Cyber Observable Event instance) or could potentially be observed (in the case of a Cyber Observable Event pattern). + + + + + The Actions construct enables description/specification of one or more cyber observable actions. + + + + + The Frequency field conveys a targeted observation pattern of the frequency of the associated event or action. + + + + + + + This Event construct is included recursively to enable description/specification of composite Events. + + + + + + + The id field specifies a unique id for this Event. + + + + + The idref field specifies a unique id reference to an Event defined elsewhere. + + + + + + The FrequencyType is a type representing the specification of a frequency for a given action or event. + + + + This field specifies the rate for this defined frequency. + + + + + This field specifies the units for this defined frequency. + + + + + This field specifies the time scale for this defined frequency. + + + + + This field is optional and conveys a targeted observation pattern of the nature of any trend in the frequency of the associated event or action. This field would be leveraged within an event or action pattern observable triggering on the matching of a specified trend in the frequency of an event or action. + + + + + + + The Action construct enables description/specification of a single cyber observable action. + + + + + The ActionsType is a complex type representing a set of cyber observable actions. + + + + + The Action construct enables description/specification of a single cyber observable action. + + + + + + + The ActionType is a complex type representing a single cyber observable action. + + + + + The Type field is optional and utilizes a standardized controlled vocabulary to specify the basic type of the action that was performed. + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is ActionTypeVocab in the http://cybox.mitre.org/default_vocabularies-2 namespace. This type is defined in the cybox_default_vocabularies.xsd file or at the URL http://cybox.mitre.org/XMLSchema/default_vocabularies/2.0/cybox_default_vocabularies.xsd. + Users may also define their own vocabulary using the type extension mechanism (by specifying a vocabulary name and/or reference using the vocab_name and vocab_reference attributes, respectively) or simply use this as a string field. + + + + + + The Name field is optional and utilizes a standardized controlled vocabulary to identify/characterize the specific name of the action that was performed. + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is ActionNameVocab in the http://cybox.mitre.org/default_vocabularies-2 namespace. This type is defined in the cybox_default_vocabularies.xsd file or at the URL http://cybox.mitre.org/XMLSchema/default_vocabularies/2.0/cybox_default_vocabularies.xsd. + Users may also define their own vocabulary using the type extension mechanism (by specifying a vocabulary name and/or reference using the vocab_name and vocab_reference attributes, respectively) or simply use this as a string field. + + + + + + The Description field contains a textual description of the action. + + + + + The Action_Aliases field is optional and enables identification of other potentially used names for this Action. + + + + + The Action_Arguments field is optional and enables the specification of relevant arguments/parameters for this Action. + + + + + The Discovery_Method field is optional and enables descriptive specification of how this Action was observed (in the case of a Cyber Observable Action instance) or could potentially be observed (in the case of a Cyber Observable Action pattern). + + + + + The Associated_Objects construct is optional and enables the description/specification of cyber Objects relevant (either initiating or affected by) this Action. + + + + + The Relationships construct is optional and enables description of other cyber observable actions that are related to this Action. + + + + + The Frequency field conveys a targeted observation pattern of the frequency of the associated event or action. + + + + + + The id field specifies a unique id for this Action. + + + + + The idref field specifies a unique id reference to an Action defined elsewhere. + + + + + The ordinal_position field is intended to reference the ordinal position of the action with within a series of actions. + + + + + The action_status field enables description of the status of the action being described. + + + + + The context field is optional and enables simple characterization of the broad operational context in which the Action is relevant + + + + + The timestamp field represents the local or relative time at which the action occurred or was observed. + + + + + + ActionStatusTypeEnum is a (non-exhaustive) enumeration of cyber observable action status types. + + + + + Specifies a cyber observable action that was successful. + + + + + Specifies a cyber observable action that failed. + + + + + Specifies a cyber observable action that resulted in an error. + + + + + Specifies a cyber observable action that completed or finished. This action status does not specify the result of the action (e.g., Success/Error). + + + + + Specifies a cyber observable action is pending. + + + + + Specifies a cyber observable action that is ongoing. + + + + + Specifies a cyber observable action with an unknown status. + + + + + + + ActionContextTypeEnum is a (non-exhaustive) enumeration of cyber observable action contexts. + + + + + Specifies that the cyber observable action occurred on a host. + + + + + Specifies that the cyber observable action occurred on a network. + + + + + + + The ActionAliasesType enables identification of other potentially used names for this Action. + + + + + The Action_Alias field is optional and enables identification of a single other potentially used name for this Action. + + + + + + + The ActionArgumentsType enables the specification of relevant arguments/parameters for this Action. + + + + + The Action_Argument construct is optional and enables the specification of a single relevant argument/parameter for this Action. + + + + + + + The ActionArgumentType enables the specification of a single relevant argument/parameter for this Action. + + + + + The Defined_Argument_Name field is optional and utilizes a standardized controlled vocabulary to identify/characterize the specific action argument utilized. + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is ActionArgumentNameVocab in the http://cybox.mitre.org/default_vocabularies-2 namespace. This type is defined in the cybox_default_vocabularies.xsd file or at the URL http://cybox.mitre.org/XMLSchema/default_vocabularies/2.0/cybox_default_vocabularies.xsd. + Users may also define their own vocabulary using the type extension mechanism (by specifying a vocabulary name and/or reference using the vocab_name and vocab_reference attributes, respectively) or simply use this as a string field. + + + + + + The Argument_Value field specifies the value for this action argument/parameter. + + + + + + + The AssociatedObjectsType enables the description/specification of cyber Objects relevant to an Action. + + + + + The Associated_Object construct enables the description of cyber Objects associated with this Action. This could include Objects that initiated the action, are the target Objects affected by the Action, are utilized by the Action or are the returned result of the Action. + + + + + + + The AssociatedObjectType is a complex type representing the characterization of a cyber observable Object associated with a given cyber observable Action. + + + + + + + The Association_Type field utilizes a standardized controlled vocabulary to specify the kind of association this Object holds for this Action. + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is ActionObjectAssociationTypeVocab in the http://cybox.mitre.org/default_vocabularies-2 namespace. This type is defined in the cybox_default_vocabularies.xsd file or at the URL http://cybox.mitre.org/XMLSchema/default_vocabularies/2.0/cybox_default_vocabularies.xsd. + Users may also define their own vocabulary using the type extension mechanism (by specifying a vocabulary name and/or reference using the vocab_name and vocab_reference attributes, respectively) or simply use this as a string field. + + + + + + The Action_Pertinent_Object_Properties construct is optional and identifies which of the Properties of this Object are specifically pertinent to this Action. + + + + + + + + + The ActionPertinentObjectPropertiesType identifies which of the Properties of this Object are specifically pertinent to this Action. + + + + + The Property construct identifies a single Object Property that is specifically pertinent to this Action. + + + + + + + The ActionPertinentObjectPropertyType identifies one of the Properties of an Object that specifically pertinent to an Action. + + + + The name field specifies the field name for the pertinent Object Property. + + + + + The xpath field specifies the XPath 1.0 expression identifying the pertinent property within the Properties schema for this object type. + + + + + + The RelationshipsType enables description of other cyber observable actions that are related to this Action. + + + + + The Relationship construct is optional and enables description of a single other cyber observable action that is related to this Action. + + + + + + + The ActionRelationshipType characterizes a relationship between a specified cyber observable action and another cyber observable action. + + + + + The Type field utilizes a standardized controlled vocabulary to describe the nature of the relationship between this Action and the related Action. + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is ActionRelationshipTypeVocab in the http://cybox.mitre.org/default_vocabularies-2 namespace. This type is defined in the cybox_default_vocabularies.xsd file or at the URL http://cybox.mitre.org/XMLSchema/default_vocabularies/2.0/cybox_default_vocabularies.xsd. + Users may also define their own vocabulary using the type extension mechanism (by specifying a vocabulary name and/or reference using the vocab_name and vocab_reference attributes, respectively) or simply use this as a string field. + + + + + The Action_Reference construct captures references to other Actions. + + + + + + + ActionReferenceType is intended to serve as a method for linking to actions. + + + + The action_id field refers to the id of the action being referenced. + + + + + + + The Object construct identifies and specificies the characteristics of a specific cyber-relevant object (e.g. a file, a registry key or a process). + + + + + The ObjectType is a complex type representing the characteristics of a specific cyber-relevant object (e.g. a file, a registry key or a process). + + + + + The State field enables the description of the current state of the object, through a standardized controlled vocabulary. + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is ObjectStateVocab in the http://cybox.mitre.org/default_vocabularies-2 namespace. This type is defined in the cybox_default_vocabularies.xsd file or at the URL http://cybox.mitre.org/XMLSchema/default_vocabularies/2.0/cybox_default_vocabularies.xsd. + Users may also define their own vocabulary using the type extension mechanism (by specifying a vocabulary name and/or reference using the vocab_name and vocab_reference attributes, respectively) or simply use this as a string field. + + + + + The Description field provides a mechanism to specify a structured text description of this Object. + + + + + The Properties construct is an abstract placeholder for various predefined Object type schemas (e.g. File, Process or System) that can be instantiated in its place through extension of the ObjectPropertiesType. This mechanism enables the specification of a broad range of Object types with consistent Object Property naming and structure. The set of Properties schemas are maintained independent of the core CybOX schema. + + + + + The Domain_Specific_Object_Properties construct is of an Abstract type placeholder within the CybOX schema enabling the inclusion of domain-specific metadata for an object through the use of a custom type defined as an extension of this base Abstract type. This enables domains utilizing CybOX such as malware analysis or forensics to incorporate non-generalized object metadata from their domains into CybOX objects. + + + + + The Related_Objects construct is optional and enables the identification and/or specification of Objects with relevant relationships with this Object. + + + + + The Defined_Effect construct is an abstract placeholder for various predefined Object Effect types (e.g. DataReadEffect, ValuesEnumeratedEffect or StateChangeEffect) that can be instantiated in its place through extension of the DefinedEffectType. This mechanism enables the specification of a broad range of types of potential complex action effects on Objects. The set of Defined_Effect types (extending the DefeinedEffectType) are maintained as part of the core CybOX schema. + + + + + The Discovery_Method field is optional and enables descriptive specification of how this Object was observed (in the case of a Cyber Observable Object instance) or could potentially be observed (in the case of a Cyber Observable Object pattern). + + + + + + The id field specifies a unique id for this Object. + + + + + The idref field specifies a unique id reference to an Object defined elsewhere. + + + + + The has_changed field is optional and conveys a targeted observation pattern of whether the associated object specified has changed. This field would be leveraged within a pattern observable triggering on whether the value of an object specification has changed. + + + + + + The DomainSpecificObjectPropertiesType is an abstract type placeholder within the CybOX schema enabling the inclusion of domain-specific metadata for an object through the use of a custom type defined as an extension of this base Abstract type. This enables domains utilizing CybOX such as malware analysis or forensics to incorporate non-generalized object metadata from their domains into CybOX objects. + + + + + The RelatedObjectsType enables the identification and/or specification of Objects with relevant relationships with this Object. + + + + + The Related_Object construct is optional and enables the identification and/or specification of a single Objects with relevant relationships with this Object. + + + + + + + The RelatedObjectType enables the identification and/or specification of an Object with a relevant relationship with this Object. + + + + + + + The Relationship field uses a standardized controlled vocabulary to capture the nature of the relationship between this Object and the Related_Object. + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is ObjectRelationshipVocab in the http://cybox.mitre.org/default_vocabularies-2 namespace. This type is defined in the cybox_default_vocabularies.xsd file or at the URL http://cybox.mitre.org/XMLSchema/default_vocabularies/2.0/cybox_default_vocabularies.xsd. + Users may also define their own vocabulary using the type extension mechanism (by specifying a vocabulary name and/or reference using the vocab_name and vocab_reference attributes, respectively) or simply use this as a string field. + + + + + + + + + The DefinedEffectType is an abstract placeholder for various predefined Object Effect types (e.g. DataReadEffect, ValuesEnumeratedEffect or StateChangeEffect) that can be instantiated in its place through extension of the DefinedEffectType. This mechanism enables the specification of a broad range of types of potential complex action effects on Objects. The set of Defined_Effect types (extending the DefinedEffectType) are maintained as part of the core CybOX schema. + + + + The effect_type field specifies the nature of the Defined Effect instantiated in the place of the Defined_Effect element. + + + + + + EffectTypeEnum is a (non-exhaustive) enumeration of effect types. + + + + + Specifies that the associated Action had an effect on the Object of changing its state. + + + + + Specifies that the associated Action had an effect on the Object of reading data from it. + + + + + Specifies that the associated Action had an effect on the Object of writing data to it. + + + + + Specifies that the associated Action had an effect on the Object of sending data to it. + + + + + Specifies that the associated Action had an effect on the Object of receiving data from it. + + + + + Specifies that the associated Action had an effect on the Object of reading properties from it. + + + + + Specifies that the associated Action had an effect on the Object of enumeraring properies from it. + + + + + Specifies that the associated Action had an effect on the Object of enumerating values from it. + + + + + Specifies that the associated Action had an effect on the Object of having a control code sent to it. + + + + + + + The StateChangeEffectType is intended as a generic way of characterizing the effects of actions upon objects where the some state of the object is changed. + + + + + + + The Old_Object construct specifies the object and its properties as they were before the state change effect occurred. + + + + + The New_Object construct specifies the object and its properties as they are after the state change effect occurred. + + + + + + + + + The DataReadEffectType type is intended to characterize the effects of actions upon objects where some data is read, such as from a file or a pipe. + + + + + + + The Data field specifies the data that was read from the object by the action. + + + + + + + + + The DataWrittenEffectType type is intended to characterize the effects of actions upon objects where some data is written, such as to a file or a pipe. + + + + + + + The Data field specifies the data that was written to the object by the action. + + + + + + + + + The DataSentEffectType type is intended to characterize the effects of actions upon objects where some data is sent, such as a byte sequence on a socket. + + + + + + + The Data field specifies the data that was sent on the object, or from the object, by the action. + + + + + + + + + The DataReceivedEffectType type is intended to characterize the effects of actions upon objects where some data is received, such as a byte sequence on a socket. + + + + + + + The Data field specifies the data that was received on the object, or from the object, by the action. + + + + + + + + + The PropertyReadEffectType type is intended to characterize the effects of actions upon objects where some specific property is read from an object, such as the current running state of a process. + + + + + + + The Name field specifies the Name of the property being read. + + + + + The Value field specifies the value of the property being read. + + + + + + + + + The PropertiesEnumeratedEffectType type is intended to characterize the effects of actions upon objects where some properties of the object are enumerated, such as the startup parameters for a process. + + + + + + + The Properties field specifies the properties that were enumerated as a result of the action on the object. + + + + + + + + + The PropertiesType specifies the properties that were enumerated as a result of the action on the object. + + + + + The Property elemet specifies a single property that was enumerated as a result of the action on the object. + + + + + + + The ValuesEnumeratedEffectType type is intended to characterize the effects of actions upon objects where some values of the object are enumerated, such as the values of a registry key. + + + + + + + The Values field specifies the values that were enumerated as a result of the action on the object. + + + + + + + + + The ValuesType specifies the values that were enumerated as a result of the action on the object. + + + + + The Value field specifies a single value that was enumerated as a result of the action on the object. + + + + + + + The SendControlCodeEffectType is intended to characterize the effects of actions upon objects where some control code, or other control-oriented communication signal, is sent to the object. For example, an action may send a control code to change the running state of a process. + + + + + + + The Control_Code field specifies the actual control code that was sent to the object. + + + + + + + + + + The Property element represents the specification of a single Object Property + + + + + + The ObservablesCompositionType enables the specification of higher-order composite observables composed of logical combinations of other observables. + + + + + The Observable construct represents a description of a single cyber observable. + + + + + + The operator field enables the specification of complex compositional cyber observables by providing logical operators for defining interrelationships between constituent cyber observables defined utilizing the recursive Observable element. + + + + + + OperatorTypeEnum is a (non-exhaustive) enumeration of operators. + + + + + Specifies the AND logical composition operation. + + + + + Specifies the OR logical composition operation. + + + + + + + + The PoolsType enables the description of Events, Actions, Objects and Properties in a space-efficient pooled manner with the actual Observable structures defined in the CybOX schema containing references to the pooled elements. This reduces redundancy caused when identical observable elements occur multiple times within a set of defined Observables. + + + + + The Event_Pool construct enables the description of CybOX Events in a space-efficient pooled manner with the actual Observable structures defined in the CybOX schema containing references to the pooled Event elements. This reduces redundancy caused when identical Events occur multiple times within a set of defined Observables. + + + + + The Action_Pool construct enables the description of CybOX Actions in a space-efficient pooled manner with the actual Observable structures defined in the CybOX schema containing references to the pooled Action elements. This reduces redundancy caused when identical Actions occur multiple times within a set of defined Observables. + + + + + The Object_Pool construct enables the description of CybOX Objects in a space-efficient pooled manner with the actual Observable structures defined in the CybOX schema containing references to the pooled Object elements. This reduces redundancy caused when identical Objects occur multiple times within a set of defined Observables. + + + + + The Property_Pool construct enables the description of CybOX Properties in a space-efficient pooled manner with the actual Observable structures defined in the CybOX schema containing references to the pooled Properties elements. This reduces redundancy caused when identical Properties occur multiple times within a set of defined Observables. + + + + + + + The EventPoolType enables the description of CybOX Events in a space-efficient pooled manner with the actual Observable structures defined in the CybOX schema containing references to the pooled Event elements. This reduces redundancy caused when identical Events occur multiple times within a set of defined Observables. + + + + + The Event construct enables specification of a cyber observable event that is dynamic in nature with specific action(s) taken against specific cyber relevant objects (e.g. a file is deleted, a registry key is created or an HTTP Get Request is received). + + + + + + + The ActionPoolType enables the description of CybOX Actions in a space-efficient pooled manner with the actual Observable structures defined in the CybOX schema containing references to the pooled Action elements. This reduces redundancy caused when identical Actions occur multiple times within a set of defined Observables. + + + + + The Action construct enables description/specification of a single cyber observable action. + + + + + + + The ObjectPoolType enables the description of CybOX Objects in a space-efficient pooled manner with the actual Observable structures defined in the CybOX schema containing references to the pooled Object elements. This reduces redundancy caused when identical Objects occur multiple times within a set of defined Observables. + + + + + The Object construct identifies and specificies the characteristics of a specific cyber-relevant object (e.g. a file, a registry key or a process). + + + + + + + The PropertyPoolType enables the description of CybOX Properties in a space-efficient pooled manner with the actual Observable structures defined in the CybOX schema containing references to the pooled Properties elements. This reduces redundancy caused when identical Properties occur multiple times within a set of defined Observables. + + + + + The Property construct enables the specification of a single Object Property. + + + + + + + + NoisinessEnum is a (non-exhaustive) enumeration of potential levels of noisiness for a given observable pattern. + + + + + Specifies that this observable has a high level of noisiness meaning a potentially high level of false positives. + + + + + Specifies that this observable has a medium level of noisiness meaning a potentially medium level of false positives. + + + + + Specifies that this observable has a low level of noisiness meaning a potentially low level of false positives. + + + + + + + The ObfuscationTechniquesType enables the description of a set of potential techniques an attacker could leverage to obfuscate the observability of this Observable. + + + + + The Obfuscation_Technique field is optional and enables the description of a single potential technique an attacker could leverage to obfuscate the observability of this Observable. + + + + + + + The ObfuscationTechniqueType enables the description of a single potential technique an attacker could leverage to obfuscate the observability of this Observable. + + + + + The Description field captures a structured text description of the obfuscation technique. + + + + + The Observables construct is optional and enables description of potential cyber observables that could indicate the use of this particular obfuscation technique. + + + + + + + The EaseOfObfuscationEnum is a (non-exhaustive) enumeration of simple characterizations of how easy it would be for an attacker to obfuscate the observability of this Observable. + + + + + Specifies that this observable is very easy to obfuscate and hide. + + + + + Specifies that this observable is somewhat easy to obfuscate and hide. + + + + + Specifies that this observable is not very easy to obfuscate and hide. + + + + + + + + + Each keyword element contains one keyword. + + + + + + + + + The Noisiness field is optional and enables simple characterization of how noisy this Observable typically could be. In other words, how likely is it to generate false positives. + + + + + The Ease_of_Obfuscation field is optional and enables simple characterization of how easy it would be for an attacker to obfuscate the observability of this Observable. + + + + + The Obfuscation_Techniques field is optional and enables the description of potential techniques an attacker could leverage to obfuscate the observability of this Observable. + + + + + diff --git a/stix_validator/schema/cybox/cybox_default_vocabularies.xsd b/stix_validator/schema/cybox/cybox_default_vocabularies.xsd new file mode 100755 index 0000000..27bef93 --- /dev/null +++ b/stix_validator/schema/cybox/cybox_default_vocabularies.xsd @@ -0,0 +1,3106 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + cybox_default_vocabularies + 2.0.0 + 04/05/2013 9:00:00 AM + The following defines types for default controlled vocabularies used within CybOX. An individual vocabulary may be revised at any time. Revisions to vocabularies will result in the creation of new types with the new version number embedded in the name of those types. Vocabularies can be reference from CybOX elements through the use of xsi:Type. The individual elements where this may be done indicate the expected default vocabulary. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The ActionTypeVocab is the default CybOX vocabulary for Action Types, captured via the ActionType/Type element in CybOX Core. + + + + + + + + + + + + + + ActionTypeEnum is a (non-exhaustive) enumeration of cyber observable action types. + + + + + Specifies the atomic action of accepting an object or value. + + + + + Specifies the atomic action of accessing an object. + + + + + Specifies the atomic action of adding an object. + + + + + Specifies the atomic action of issuing an alert. + + + + + Specifies the atomic action of allocating an object. + + + + + Specifies the atomic action of archiving an object or data. + + + + + Specifies the atomic action of assigning a value to an object. + + + + + Specifies the atomic action of auditing an object or data. + + + + + Specifies the atomic action of backing up an object or data. + + + + + Specifies the atomic action of binding two objects. + + + + + Specifies the atomic action of blocking access to an object or resource. + + + + + Specifies the atomic action of calling an object or resource. + + + + + Specifies the atomic action of changing an object. + + + + + Specifies the atomic action of checking an object. + + + + + Specifies the atomic action of cleaning an object, such as a file system. + + + + + Specifies the atomic action of clicking an object, as with a mouse. + + + + + Specifies the atomic action of closing an object, such as a window handle. + + + + + Specifies the atomic action of comparing two objects. + + + + + Specifies the atomic action of compressing an object. + + + + + Specifies the atomic action of configuring a resource. + + + + + Specifies the atomic action of connecting to an object, such as a service or resource. + + + + + Specifies the atomic action of controlling an object or data. + + + + + Specifies the atomic action of copying or duplicating an object or data EXCEPT in cases where the object is considered a thread or process as a whole. + + + + + Specifies the atomic action of creating an object or data. + + + + + Specifies the atomic action of decoding an object or data. + + + + + Specifies the atomic action of decompressing an object, such as an archive. + + + + + Specifies the atomic action of decrypting an object. + + + + + Specifies the atomic action of denying access to a object or resource. + + + + + Specifies the atomic action of depressing an object that has been pressed, such a button. + + + + + Specifies the atomic action of detecting an object. + + + + + Specifies the atomic action of disconnecting from a service or resource. + + + + + Specifies the atomic action of downloading an object or data. + + + + + Specifies the atomic action of drawing an object. + + + + + Specifies the atomic action of dropping an object, such as a connection. + + + + + Specifies the atomic action of encoding an object or data. + + + + + Specifies the atomic action of encrypting an object or data. + + + + + Specifies the atomic action of enumerating a list of objects. + + + + + Specifies the atomic action of executing an object, such as an executable file. + + + + + Specifies the atomic action of extracting an object. + + + + + Specifies the atomic action of filtering an object or data. + + + + + Specifies the atomic action of finding an object or data. + + + + + Specifies the atomic action of flushing an object or data, such as a cache. + + + + + Specifies the atomic action of forking, as with a process. Because this is usually associated with processes and threads and does not generalize to objects, it is DIFFERENT from Copy/Duplicate. + + + + + Specifies the atomic action of freeing an object. + + + + + Specifies the atomic action of getting a value from an object. + + + + + Specifies the atomic action of hooking an object to another object. + + + + + Specifies the atomic action of hiding an object. + + + + + Specifies the atomic action of impersonation, in which an object performs actions that assume the character or appearance of another object. + + + + + Specifies the atomic action of initializing an object. + + + + + Specifies the atomic action of injecting an object. + + + + + Specifies the atomic action of installing an object, such as an application, program, patch, or other resource. + + + + + Specifies the atomic action of interleaving an object, i.e. the action of arranging data in a non-contiguous way to increase performance. + + + + + Specifies the atomic action of joining one object to another object. + + + + + Specifies the atomic action of killing an object, as with a thread or program. + + + + + Specifies the atomic action of listening to an object, such as to a port on a network connection. + + + + + Specifies the atomic action of loading an object. + + + + + Specifies the atomic action of locking an object. + + + + + Specifies the atomic action of logging into an object, such as into a system or application. + + + + + Specifies the atomic action of logging out of an object, such as a system or application. + + + + + Specifies the atomic action of mapping an object to another object or data. + + + + + Specifies the atomic action of merging one object to another object. + + + + + Specifies the atomic action of modifying an object. + + + + + Specifies the atomic action of monitoring the state of an object. + + + + + Specifies the atomic action of moving an object. + + + + + Specifies the atomic action of opening an object. + + + + + Specifies the atomic action of packing an object. + + + + + Specifies the atomic action of pausing an object, such as a thread or process. + + + + + Specifies the atomic action of pressing an object, such as a button. + + + + + Specifies the atomic action of protecting an object. + + + + + Specifies the atomic action of placing an object in quarantine, that is, to store the object in an isolated area away from other objects it can operate on. + + + + + Specifies the atomic action of querying an object. + + + + + Specifies the atomic action of queueing an object. + + + + + Specifies the atomic action of raising an object. + + + + + Specifies the atomic action of reading an object. + + + + + Specifies the atomic action of receiving an object. + + + + + Specifies the atomic action of releasing an object. + + + + + Specifies the atomic action of renaming an object. + + + + + Specifies the atomic action of removing or deleting an object. + + + + + Specifies the atomic action of replicating an object. + + + + + Specifies the atomic action of restoring an object. + + + + + Specifies the atomic action of resuming an object, as with a process or thread. + + + + + Specifies the atomic action of reverting an object. + + + + + Specifies the atomic action of running an object, such as an application. + + + + + Specifies the atomic action of saving an object. + + + + + Specifies the atomic action of scanning for an object or data. + + + + + Specifies the atomic action of scheduling an object, such as an event. + + + + + Specifies the atomic action of searching for an object. + + + + + Specifies the atomic action of sending an object. + + + + + Specifies the atomic action of setting an object to a value. + + + + + Specifies the atomic action of shutting down an object. + + + + + Specifies the atomic action of putting to sleep an object. + + + + + Specifies the atomic action taking a snapshot of an object. + + + + + Specifies the atomic action of starting an object, such as a thread or process. + + + + + Specifies the atomic action of stopping an object, such as a thread or process. + + + + + Specifies the atomic action of suspending an object, such an account or privileges for an account. + + + + + Specifies the atomic action of synchronizing an object. + + + + + Specifies the atomic action of throwing an object, such as an exception in a programming language. + + + + + Specifies the atomic action of transmitting an object. + + + + + Specifies the atomic action of unblocking an object. + + + + + Specifies the atomic action of unhiding an object. + + + + + Specifies the atomic action of unhooking an object from another object, that is, to detach. + + + + + Specifies the atomic action of uninstalling an object. + + + + + Specifies the atomic action of unloading an object. + + + + + Specifies the atomic action of unlocking an object. + + + + + Specifies the atomic action of unmapping an object from another object or data. + + + + + Specifies the atomic action of unpacking an object, such as an archive. + + + + + Specifies the atomic action of updating an object. + + + + + Specifies the atomic action of upgrading an object. + + + + + Specifies the atomic action of uploading an object. + + + + + Specifies the atomic action of wiping, destroying, or purging an object. + + + + + Specifies the atomic action of writing an object. + + + + + + + The ActionNameVocab is the default CybOX vocabulary for Action Types, captured via the ActionType/Name element in CybOX Core. + + + + + + + + + + + + + + The ActionNameEnum type is an enumeration of defined action names. + + + + + Specifies the defined action of accepting a socket connection. + + + + + Specifies the defined action of adding a connection to an existing network share. + + + + + Specifies the defined action of adding a new network share. + + + + + Specifies the defined action of adding a new system call hook. + + + + + Specifies the defined action of adding a new user. + + + + + Specifies the defined action of adding a new Windows hook. + + + + + Specifies the defined action of adding a scheduled task. + + + + + Specifies the defined action of allocating virtual memory in a process. + + + + + Specifies the defined action of binding an address to a socket. + + + + + Specifies the defined action of changing the service configuration. + + + + + Specifies the defined action of checking for a remote debugger. + + + + + Specifies the defined action of closing a port. + + + + + Specifies the defined action of closing a registry key. + + + + + Specifies the defined action of closing a socket. + + + + + Specifies the defined action of configuring a service. + + + + + Specifies the defined action of connecting to an IP address. + + + + + Specifies the defined action of connecting to a named pipe. + + + + + Specifies the defined action of connecting to a network share. + + + + + Specifies the defined action of connecting to a socket. + + + + + Specifies the defined action of connecting to a URL. + + + + + Specifies the defined action of controlling a driver. + + + + + Specifies the defined action of controlling a service. + + + + + Specifies the defined action of copying a file. + + + + + Specifies the defined action of creating a dialog box. + + + + + Specifies the defined action of creating a new directory. + + + + + Specifies the defined action of creating an event. + + + + + Specifies the defined action of creating a file. + + + + + Specifies the defined action of creating an alternate data stream in a file. + + + + + Specifies the defined action of creating a new file mapping. + + + + + Specifies the defined action of creating a file symbolic link. + + + + + Specifies the defined action of creating a hidden file. + + + + + Specifies the defined action of creating a mailslot. + + + + + Specifies the defined action of creating a module. + + + + + Specifies the defined action of creating a mutex. + + + + + Specifies the defined action of creating a named pipe. + + + + + Specifies the defined action of creating a process. + + + + + Specifies the defined action of creating a process as user. + + + + + Specifies the defined action of creating a registry key. + + + + + Specifies the defined action of creating a registry key value. + + + + + Specifies the defined action of creating a remote thread in a process. + + + + + Specifies the defined action of creating a service. + + + + + Specifies the defined action of creating a socket. + + + + + Specifies the defined action of creating a symbolic link. + + + + + Specifies the defined action of creating a thread. + + + + + Specifies the defined action of creating a window. + + + + + Specifies the defined action of deleting a directory. + + + + + Specifies the defined action of deleting a file. + + + + + Specifies the defined action of deleting a named pipe. + + + + + Specifies the defined action of deleting a network share. + + + + + Specifies the defined action of deleting a registry key. + + + + + Specifies the defined action of deleting a registry key value. + + + + + Specifies the defined action of deleting a service. + + + + + Specifies the defined action of deleting a user. + + + + + Specifies the defined action of disconnecting from a named pipe. + + + + + Specifies the defined action of disconnecting from a network share. + + + + + Specifies the defined action of disconnecting from a socket. + + + + + Specifies the defined action of downloading a file. + + + + + Specifies the defined action of enumerating DLLs. + + + + + Specifies the defined action of enumerating network shares. + + + + + Specifies the defined action of enumerating protocols. + + + + + Specifies the defined action of enumerating registry key subkeys. + + + + + Specifies the defined action of enumerating registry key values. + + + + + Specifies the defined action of enumerating threads in a process. + + + + + Specifies the defined action of enumerating processes. + + + + + Specifies the defined action of enumerating services. + + + + + Specifies the defined action of enumerating system handles. + + + + + Specifies the defined action of enumerating threads. + + + + + Specifies the defined action of enumerating users. + + + + + Specifies the defined action of enumerating windows. + + + + + Specifies the defined action of finding a file. + + + + + Specifies the defined action of finding a window. + + + + + Specifies the defined action of flushing the Process Instruction Cache. + + + + + Specifies the defined action of freeing a library. + + + + + Specifies the defined action of freeing virtual memory from a process. + + + + + Specifies the defined action of getting the amount of free space available on a disk. + + + + + Specifies the defined action of getting the disk type. + + + + + Specifies the defined action of getting the elapsed system up-time. + + + + + Specifies the defined action of getting file attributes. + + + + + Specifies the defined action of getting the function address. + + + + + Specifies the defined action of getting system global flags. + + + + + Specifies the defined action of getting host by address. + + + + + Specifies the defined action of getting host by name. + + + + + Specifies the defined action of getting the host name. + + + + + Specifies the defined action of getting the library file name. + + + + + Specifies the defined action of getting the library handle. + + + + + Specifies the defined action of getting the NetBIOS name. + + + + + Specifies the defined action of getting the process's current directory. + + + + + Specifies the defined action of getting the process environment variable. + + + + + Specifies the defined action of getting the process startup information. + + + + + Specifies the defined action of getting the processes snapshot. + + + + + Specifies the defined action of getting the attributes of a registry key. + + + + + Specifies the defined action of getting the service status. + + + + + Specifies the defined action of getting the system global flags. + + + + + Specifies the defined action of getting the local time on a system. + + + + + Specifies the defined action of getting the system host name. + + + + + Specifies the defined action of getting the NetBIOS name of a system. + + + + + Specifies the defined action of getting the system network parameters. + + + + + Specifies the defined action of getting the system time. + + + + + Specifies the defined action of getting the thread context. + + + + + Specifies the defined action of getting the thread username. + + + + + Specifies the defined action of getting the attributes of a user. + + + + + Specifies the defined action of getting a username. + + + + + Specifies the defined action of getting a windows directory. + + + + + Specifies the defined action of getting a windows System directory. + + + + + Specifies the defined action of getting the Windows Temporary Files Directory. + + + + + Specifies the defined action of hiding a window. + + + + + Specifies the defined action of impersonating a process. + + + + + Specifies the defined action of impersonating a thread. + + + + + Specifies the defined action of injecting a memory page into a process. + + + + + Specifies the defined action of killing a process. + + + + + Specifies the defined action of killing a thread. + + + + + Specifies the defined action of killing a window. + + + + + Specifies the defined action of listening on a specific port. + + + + + Specifies the defined action of listening on a socket. + + + + + Specifies the defined action of loading and calling a driver. + + + + + Specifies the defined action of loading a driver. + + + + + Specifies the defined action of loading a library. + + + + + Specifies the defined action of loading a module. + + + + + Specifies the defined action of locking a file. + + + + + Specifies the defined action of logging on as a user. + + + + + Specifies the defined action of mapping a file. + + + + + Specifies the defined action of mapping a library. + + + + + Specifies the defined action of mapping a view of a file. + + + + + Specifies the defined action of modifying a file. + + + + + Specifies the defined action of modifying a named pipe. + + + + + Specifies the defined action of modifying a process. + + + + + Specifies the defined action of modifying a service. + + + + + Specifies the defined action of modifying a registry key. + + + + + Specifies the defined action of modifying a registry key value. + + + + + Specifies the defined action of monitoring a registry key. + + + + + Specifies the defined action of moving a file. + + + + + Specifies the defined action of opening a file. + + + + + Specifies the defined action of opening a file mapping. + + + + + Specifies the defined action of opening a mutex. + + + + + Specifies the defined action of opening a port. + + + + + Specifies the defined action of opening a process. + + + + + Specifies the defined action of opening a registry key. + + + + + Specifies the defined action of opening a service. + + + + + Specifies the defined action of opening a service control manager. + + + + + Specifies the defined action of protecting virtual memory. + + + + + Specifies the defined action of querying disk attributes. + + + + + Specifies the defined action of querying DNS. + + + + + Specifies the defined action of querying process virtual memory. + + + + + Specifies the defined action of querying the Asynchronized Procedure Call (APC) in the context of a thread. + + + + + Specifies the defined action of reading a file. + + + + + Specifies the defined action of reading from a named pipe. + + + + + Specifies the defined action of reading from process memory. + + + + + Specifies the defined action of reading a registry key value. + + + + + Specifies the defined action of receiving data on a socket. + + + + + Specifies the defined action of releasing a mutex. + + + + + Specifies the defined action of renaming a file. + + + + + Specifies the defined action of reverting a thread to its self. + + + + + Specifies the defined action of sending a control code to a file. + + + + + Specifies the defined action of sending a control code to a pipe. + + + + + Specifies the defined action of sending control code to a service. + + + + + Specifies the defined action of sending data on a socket. + + + + + Specifies the defined action of sending data to the address on a socket. + + + + + Specifies the defined action of sending a DNS query. + + + + + Specifies the defined action of sending an email message. + + + + + Specifies the defined action of sending an ICMP request. + + + + + Specifies the defined action of sending a reverse DNS query. + + + + + Specifies the defined action of setting file attributes. + + + + + Specifies the defined action of setting the NetBIOS name. + + + + + Specifies the defined action of setting the process current directory. + + + + + Specifies the defined action of setting the process environment variable. + + + + + Specifies the defined action of setting system global flags. + + + + + Specifies the defined action of setting the system host name. + + + + + Specifies the defined action of setting the system time. + + + + + Specifies the defined action of setting the thread context. + + + + + Specifies the defined action of showing a window. + + + + + Specifies the defined action of shutting down a system. + + + + + Specifies the defined action of sleeping a process. + + + + + Specifies the defined action of sleeping a system. + + + + + Specifies the defined action of starting a service. + + + + + Specifies the defined action of unloading a driver. + + + + + Specifies the defined action of unlocking a file. + + + + + Specifies the defined action of unmapping a file. + + + + + Specifies the defined action of unloading a module. + + + + + Specifies the defined action of uploading a file. + + + + + Specifies the defined action of writing to a file. + + + + + Specifies the defined action of writing to process virtual memory. + + + + + + + The ActionArgumentNameVocab is the default CybOX vocabulary for Action Argument Names, captured via the ActionArgumentType/Argument_Name element in CybOX Core. + + + + + + + + + + + + + + The ActionArgumentNameEnum type is an enumeration of defined argument names. + + + + + Specifies an argument called API. + + + + + Specifies an argument called Creation Flags. + + + + + Specifies an argument called Access Mode. + + + + + Specifies an argument called Share Mode. + + + + + Specifies an argument called Callback Address. + + + + + Specifies an argument called Source Address. + + + + + Specifies an argument called Destination Address. + + + + + Specifies an argument called Starting Address. + + + + + Specifies an argument called Size (bytes). + + + + + Specifies an argument called Control Parameter. + + + + + Specifies an argument called Host Name. + + + + + Specifies an argument called Function Name. + + + + + Specifies an argument called Function Address. + + + + + Specifies an argument called Options. + + + + + Specifies an argument called Transfer Flags. + + + + + Specifies an argument called Control Code. + + + + + Specifies an argument called APC Mode. + + + + + Specifies an argument called APC Address. + + + + + Specifies an argument called Base Address. + + + + + Specifies an argument called Protection. + + + + + Specifies an argument called Target PID. + + + + + Specifies an argument called Mapping Offset. + + + + + Specifies an argument called File Information Class. + + + + + Specifies an argument called Function Ordinal. + + + + + Specifies an argument called Function Name. + + + + + Specifies an argument called Hook Type. + + + + + Specifies an argument called Request Size. + + + + + Specifies an argument called Service Type. + + + + + Specifies an argument called Service State. + + + + + Specifies an argument called Group Name. + + + + + Specifies an argument called Hostname. + + + + + Specifies an argument called Shutdown Flag. + + + + + Specifies an argument called Sleep Time (ms). + + + + + Specifies an argument called Code Address. + + + + + Specifies an argument called Parameter Address. + + + + + Specifies an argument called Server. + + + + + + + The ActionObjectAssocationVocab is the default CybOX vocabulary for Action-Object association types, captured via the AssociatedObjectType/Association_Type element in CybOX Core. + + + + + + + + + + + + + + ActionObjectAssociationTypeEnum is a (non-exhaustive) enumeration of types of action-object associations. + + + + + Specifies that the associated object initiated the action. + + + + + Specifies that the associated object was affected by the action. + + + + + Specifies that the associated object was utilized by the action. + + + + + Specifies that the associated object was the result of the action. + + + + + + + The ActionObjectAssocationVocab is the default CybOX vocabulary for Action-Action relationships, captured via the ActionRelationshipType/Type element in the CybOX Core. + + + + + + + + + + + + + + The ActionRelationshipTypeEnum is an enumeration of types of relationships between actions. + + + + + Specifies that this action is preceded by the related action. + + + + + Specifies that this action is followed by the related action. + + + + + Specifies that this entity (e.g. Action) is equivalent to the associated entity. + + + + + Specifies that this action is simply related to the related action in some way. + + + + + Specifies that this action is dependent on the related action. + + + + + Specifies that this action was initiated by the related action. + + + + + Specifies that this action initiated the related action. + + + + + + + The EventTypeVocab is the default CybOX vocabulary for Event types, captured via the EventType/Type element in the CybOX Core. + + + + + + + + + + + + + + EventTypeEnum is a (non-exhaustive) enumeration of cyber observable event types. + + + + + Specifies the class of events dealing with file operations. + + + + + Specifies the class of events dealing with registry operations. + + + + + Specifies the class of events dealing with memory operations. + + + + + Specifies the class of events dealing with process management. + + + + + Specifies the class of events dealing with thread management. + + + + + Specifies the class of events dealing with service management. + + + + + Specifies the class of events dealing with session management. + + + + + Specifies the class of events dealing with API calls. + + + + + Specifies the class of events dealing with port scanning. + + + + + Specifies the class of events dealing with IP Operations. + + + + + Specifies the class of events dealing with DNS Lookup operations. + + + + + Specifies the class of events dealing with thread management. + + + + + Specifies the class of events dealing with thread management. + + + + + Specifies the class of events dealing with configuration management. + + + + + Specifies the class of events dealing with user/password management. + + + + + Specifies the class of events dealing with account operations at the application layer. + + + + + Specifies the class of events dealing with HTTP traffic. + + + + + Specifies the class of events dealing with Application Layer traffic. + + + + + Specifies the class of events dealing with packet traffic. + + + + + Specifies the class of events dealing with data flow. + + + + + Specifies the class of events dealing with anomoly events. + + + + + Specifies the class of events dealing with Technical compliance. + + + + + Specifies the class of events dealing with procedural compliance. + + + + + Specifies the class of events dealing with the GUI/Kernel-based Virtual Machine (KVM). + + + + + Specifies the class of events dealing with Autorun. + + + + + Specifies the class of events dealing with USB and/or Media detection. + + + + + Specifies the class of events dealing with the SQL language. + + + + + Specifies the class of events dealing with the Dynamic Host Configuration Protocol (DHCP). + + + + + Specifies the class of events dealing with redirection. + + + + + Specifies the class of events dealing with authentication operations. + + + + + Specifies the class of events dealing with authorization via Access Control Lists (ACL). + + + + + Specifies the class of events dealing with privilege operations. + + + + + Specifies the class of events dealing with basic system operations. + + + + + Specifies the class of events dealing with signature detection. + + + + + Specifies the class of events dealing with auto-update operations. + + + + + Specifies the class of events dealing with application logic. + + + + + Specifies the class of events dealing with e-mail operations. + + + + + + + The ObjectRelationshipVocab is the default CybOX vocabulary for Object-Object relationships, captured via the RelatedObjectType/Relationship element in CybOX Core. + + + + + + + + + + + + + + ObjectRelationshipEnum is a (non-exhaustive) enumeration of interobject relationships. + + + + + Specifies that this object created the related object. + + + + + Specifies that this object was created by the related object. + + + + + Specifies that this object deleted the related object. + + + + + Specifies that this object was deleted by the related object. + + + + + Specifies that this object modified the properties of the related object. + + + + + Specifies that the properties of this object were modified by the related object. + + + + + Specifies that this object was read from the related object. + + + + + Specifies that this object was read from by the related object. + + + + + Specifies that this object wrote to the related object. + + + + + Specifies that this object was written to by the related object. + + + + + Specifies that this object was downloaded from the related object. + + + + + Specifies that this object downloaded the related object. + + + + + Specifies that this object downloaded the related object. + + + + + Specifies that this object was downloaded by the related object. + + + + + Specifies that this object uploaded the related object. + + + + + Specifies that this object was uploaded by the related object. + + + + + Specifies that this object was uploaded to the related object. + + + + + Specifies that this object received the related object via upload. + + + + + Specifies that this object was uploaded from the related object. + + + + + Specifies that this object sent the related object via upload. + + + + + Specifies that this object suspended the related object. + + + + + Specifies that this object was suspended by the related object. + + + + + Specifies that this object paused the related object. + + + + + Specifies that this object was paused by the related object. + + + + + Specifies that this object resumed the related object. + + + + + Specifies that this object was resumed by the related object. + + + + + Specifies that this object opened the related object. + + + + + Specifies that this object was opened by the related object. + + + + + Specifies that this object closed the related object. + + + + + Specifies that this object was closed by the related object. + + + + + Specifies that this object was copied from the related object. + + + + + Specifies that this object was copied to the related object. + + + + + Specifies that this object copied the related object. + + + + + Specifies that this object was copied by the related object. + + + + + Specifies that this object was moved from the related object. + + + + + Specifies that this object was moved to the related object. + + + + + Specifies that this object moved the related object. + + + + + Specifies that this object was moved by the related object. + + + + + Specifies that this object searched for the related object. + + + + + Specifies that this object was searched for by the related object. + + + + + Specifies that this object allocated the related object. + + + + + Specifies that this object was allocated by the related object. + + + + + Specifies that this object was initialized to the related object. + + + + + Specifies that this object was initialized by the related object. + + + + + Specifies that this object sent the related object. + + + + + Specifies that this object was sent by the related object. + + + + + Specifies that this object was sent to the related object. + + + + + Specifies that this object was received from the related object. + + + + + Specifies that this object received the related object. + + + + + Specifies that this object was received by the related object. + + + + + Specifies that this object was mapped into the related object. + + + + + Specifies that this object was mapped by the related object. + + + + + Specifies that the object queried properties of the related object. + + + + + Specifies that the properties of this object were queried by the related object. + + + + + Specifies that the object enumerated values of the related object. + + + + + Specifies that the values of the object were enumerated by the related object. + + + + + Specifies that this object bound the related object. + + + + + Specifies that this object was bound by the related object. + + + + + Specifies that this object freed the related object. + + + + + Specifies that this object was freed by the related object. + + + + + Specifies that this object killed the related object. + + + + + Specifies that this object was killed by the related object. + + + + + Specifies that this object encrypted the related object. + + + + + Specifies that this object was encrypted by the related object. + + + + + Specifies that this object was encrypted to the related object. + + + + + Specifies that this object was encrypted from the related object. + + + + + Specifies that this object decrypted the related object. + + + + + Specifies that this object was decrypted by the related object. + + + + + Specifies that this object packed the related object. + + + + + Specifies that this object was packed by the related object. + + + + + Specifies that this object unpacked the related object. + + + + + Specifies that this object was unpacked by the related object. + + + + + Specifies that this object was packed from the related object. + + + + + Specifies that this object was packed into the related object. + + + + + Specifies that this object encoded the related object. + + + + + Specifies that this object was encoded by the related object. + + + + + Specifies that this object decoded the related object. + + + + + Specifies that this object was decoded by the related object. + + + + + Specifies that this object was compressed from the related object. + + + + + Specifies that this object was compressed into the related object. + + + + + Specifies that this object compressed the related object. + + + + + Specifies that this object was compressed by the related object. + + + + + Specifies that this object decompressed the related object. + + + + + Specifies that this object was decompressed by the related object. + + + + + Specifies that this object joined the related object. + + + + + Specifies that this object was joined by the related object. + + + + + Specifies that this object merged the related object. + + + + + Specifies that this object was merged by the related object. + + + + + Specifies that this object locked the related object. + + + + + Specifies that this object was locked by the related object. + + + + + Specifies that this object unlocked the related object. + + + + + Specifies that this object was unlocked by the related object. + + + + + Specifies that this object hooked the related object. + + + + + Specifies that this object was hooked by the related object. + + + + + Specifies that this object unhooked the related object. + + + + + Specifies that this object was unhooked by the related object. + + + + + Specifies that this object monitored the related object. + + + + + Specifies that this object was monitored by the related object. + + + + + Specifies that this object listened on the related object. + + + + + Specifies that this object was listened on by the related object. + + + + + Specifies that this object was renamed from the related object. + + + + + Specifies that this object was renamed to the related object. + + + + + Specifies that this object renamed the related object. + + + + + Specifies that this object was renamed by the related object. + + + + + Specifies that this object injected into the related object. + + + + + Specifies that this object injected as the related object. + + + + + Specifies that this object injected the related object. + + + + + Specifies that this object was injected by the related object. + + + + + Specifies that this object was deleted from the related object. + + + + + Specifies that this object previously contained the related object. + + + + + Specifies that this object loaded into the related object. + + + + + Specifies that this object was loaded from the related object. + + + + + Specifies that this object was set to the related object. + + + + + Specifies that this object was set from the related object. + + + + + Specifies that this object was resolved to the related object. + + + + + Specifies that this object is related to the related object. + + + + + Specifies that this object dropped the related object. + + + + + Specifies that this object was dropped by the related object. + + + + + Specifies that this object contains the related object. + + + + + Specifies that this object is contained within the related object. + + + + + Specifies that this object was extracted from the related object. + + + + + Specifies that this object installed the related object. + + + + + Specifies that this object was installed by the related object. + + + + + Specifies that this object connected to the related object. + + + + + Specifies that this object was connected to from the related object. + + + + + Specifies that this object is a sub-domain of the related object. + + + + + Specifies that this object is a supra-domain of the related object. + + + + + Specifies that this object is the root domain of the related object. + + + + + Specifies that this object is an FQDN of the related object. + + + + + Specifies that this object is a parent of the related object. + + + + + Specifies that this object is a child of the related object. + + + + + Specifies that this object describes the properties of the related object. This is most applicable in cases where the related object is an Artifact Object and this object is a non-Artifact Object. + + + + + Specifies that the related object describes the properties of this object. This is most applicable in cases where the related object is a non-Artifact Object and this object is an Artifact Object. + + + + + + + The ObjectStateVocab is the default CybOX vocabulary for Object states, captured via the ObjectType/State element in CybOX Core. + + + + + + + + + + + + + + ObjectStateEnum is a (non-exhaustive) enumeration of cyber observable object states. + + + + + Specifies that the object exists. + + + + + Specifies that the object does not exist. + + + + + Specifies that the object is open. + + + + + Specifies that the object is closed. + + + + + Specifies that the object is active. + + + + + Specifies that the object is inactive. + + + + + Specifies that the object is locked. + + + + + Specifies that the object is unlocked. + + + + + Specifies that the object has started. + + + + + Specifies that the object has stopped. + + + + + + + The CharacterEncodingVocab is the default CybOX vocabulary for character encoding, used in the ExtractedStringType/Encoding element in CybOX Common. + + + + + + + + + + + + + + CharacterEncodingEnum is a (non-exhaustive) enumeration of character encodings. + + + + + Specifies the American Standard Code for Information Interchange (ASCII) character encoding scheme. + + + + + Specifies the UCS Transformation Format-8 bit (UTF-8) character encoding scheme. + + + + + Specifies the UCS Transformation Format-16 bit (UTF-16) character encoding scheme. + + + + + Specifies the UCS Transformation Format-32 bit (UTF-32) character encoding scheme. + + + + + Specifies the Windows-1250 character encoding scheme, for Central European languages. + + + + + Specifies the Windows-1251 character encoding scheme, for Cyrillic alphabets. + + + + + Specifies the Windows-1252 character encoding scheme, for Western languages. + + + + + Specifies the Windows-1253 character encoding scheme, for Greek. + + + + + Specifies the Windows-1254 character encoding scheme, for Turkish. + + + + + Specifies the Windows-1255 character encoding scheme, for Hebrew. + + + + + Specifies the Windows-1256 character encoding scheme, for Arabic. + + + + + Specifies the Windows-1257 character encoding scheme, for Baltic languages. + + + + + Specifies the Windows-1258 character encoding scheme, for Vietnamese. + + + + + + + The InformationSourceTypeVocab is the default CybOX vocabulary for information source types, used in the MeasureSourceType/Information_Source_Type element in CybOX Common. + + + + + + + + + + + + + + The InformationSourceTypeEnum is a (non-exhaustive) enumeration of cyber observation information source types. + + + + + The Comm Logs value specifies a cyber observation coming from communications logs. + + + + + The Application Logs value specifies a cyber observation coming from application logs. + + + + + The Web Logs value specifies a cyber observation coming from web logs. + + + + + The DBMS Log value specifies a cyber observation coming from the Database Management System log. + + + + + The OS/Device Driver APIs value specifies a cyber observation coming from OS/Device Driver APIs. + + + + + The Frameworks value specifies a cyber observation coming from Frameworks. + + + + + The VM Hypervisor value specifies a cyber observation coming from the VM hypervisor data. + + + + + The TPM value specifies a cyber observation made using TPM output data. + + + + + The Application Framework value specifies a cyber observation coming from an application framework. + + + + + The Help Desk value specifies a cyber observation coming from an human or automated help desk. + + + + + The Incident Management value specifies a cyber observation made using information provided by Incident Management services. + + + + + The IAVM value specifies a cyber observation made using information provided by Information Assurance Vulnerability Management mechanisms. + + + + + + + The HashNameVocab is the default CybOX vocabulary for hashing algorithm names, used in the HashType/Type element in CybOX Common. + + + + + + + + + + + + + + HashNameEnum is a (non-exhaustive) enumeration of hashing algorithm names. + + + + + The MD5 value specifies the MD5 hashing algorithm. + + + + + The MD6 value specifies the MD6 hashing algorithm. + + + + + The SHA1 value specifies the SHA1 hashing algorithm. + + + + + The SHA24 value specifies the SHA224 hashing algorithm. + + + + + The SHA256 value specifies the SHA256 hashing algorithm. + + + + + The SHA384 value specifies the SHA384 hashing algorithm. + + + + + The SHA512 value specifies the SHA512 hashing algorithm. + + + + + The SSDEEP value specifies the SSDEEP hashing algorithm. + + + + + + + The ToolTypeVocab is the default CybOX vocabulary for tool types, used in the MeasureSourceType/Tool_Type element in CybOX Common. + + + + + + + + + + + + + + The ToolTypeEnum is a (non-exhaustive) enumeration of cyber observation source tool types. + + + + + The NIDS value specifies the Network Intrusion Detection System tool. + + + + + The NIPS value specifies the Network Intrusion Protection System tool. + + + + + The HIDS value specifies the Host-based Intrusion Detection System tool. + + + + + The HIPS value specifies the Host-based Intrusion Protection System tool. + + + + + The Firewall value specifies a cyber observation made using a firewall. + + + + + The Router value specifies a cyber observation made using a router. + + + + + The Proxy value specifies a cyber observation made using a network proxy. + + + + + The Gateway value specifies a cyber observation made using a network gateway. + + + + + The SNMP/MIBs value specifies a cyber observation made using the Simple Network Management Protocol or via the Management Information Bases. + + + + + The A/V value specifies a cyber observation made using Anti-Virus tools and/or software. + + + + + The DBMS value specifies a cyber observation made using a Database Management System monitor. + + + + + The Vulnerability Scanner value specifies a cyber observation made using a vulnerability scanner. + + + + + The Configuration Scanner value specifies a cyber observation made using a configuration scanner. + + + + + The Asset Scanner value specifies a cyber observation made using an asset scanner. + + + + + The SIM value specifies a cyber observation made using Security Information Management tools. + + + + + The SEM value specifies a cyber observation made using Security Event Management tools. + + + + + diff --git a/stix_validator/schema/cybox/extensions/platform/README.txt b/stix_validator/schema/cybox/extensions/platform/README.txt new file mode 100755 index 0000000..aea589c --- /dev/null +++ b/stix_validator/schema/cybox/extensions/platform/README.txt @@ -0,0 +1 @@ +The PlatformSpecificationType, defined in the CybOX common schema, provides a way to provide a prose description of a platform as well as any number of platform identification values. If one wishes to provide a more structured description of a platform, they can define types that extend PlatformSpecificationType. These types would be indicated using an xsi:Type attribute in the relevant element in CybOX content. This directory provides CybOX default extensions to PlatformSpecificationType to support structured description of platforms. \ No newline at end of file diff --git a/stix_validator/schema/cybox/extensions/platform/cpe2.3.xsd b/stix_validator/schema/cybox/extensions/platform/cpe2.3.xsd new file mode 100755 index 0000000..ed86477 --- /dev/null +++ b/stix_validator/schema/cybox/extensions/platform/cpe2.3.xsd @@ -0,0 +1,40 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + CPE2.3 + 1.0 + 04/03/2013 9:00:00 AM + Cyber Observable eXpression (CybOX) Extension - CPE 2.3 Platform Instance - Schematic implementation for using the CPE 2.3 Applicablity Language to describe a Platform within the CybOX observable expression language. It extends the PlatformSpecificationType defined in the CybOX common schema. (cybox_common.xsd) For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + http://scap.nist.gov/specifications/cpe/ + + + + + + + + + The CPE23PlatformSpecificationType provides an extension of the PlatformSpecificationType that imports and leverages the CPE 2.3 applicability language schema for structured characterization of a platform or platform combination. + + + + + + + The platform-specification element, defined in the CPE 2.3 Applicability Language schema, supports a structured characterization of a platform or combination of platforms. + + + + + + + diff --git a/stix_validator/schema/cybox/objects/API_Object.xsd b/stix_validator/schema/cybox/objects/API_Object.xsd new file mode 100755 index 0000000..51df15c --- /dev/null +++ b/stix_validator/schema/cybox/objects/API_Object.xsd @@ -0,0 +1,55 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + API_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The API element is intended to characterize a single Application Programming Interface. + + + + + The APIObjectType type is intended to characterize a specific Application Programming Interface. + + + + + + + The Description property is intended for use in providing a brief description of the API. + + + + + The function_name property contains the exact name of the API function called, e.g. CreateFileEx. + + + + + The normalized_function_name property contains the normalized name of the API function called, e.g. CreateFile. + + + + + The Platform property specifies the relevant platform for this API. + + + + + The Address property contains the address of the API call in the binary. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Account_Object.xsd b/stix_validator/schema/cybox/objects/Account_Object.xsd new file mode 100755 index 0000000..4995fa2 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Account_Object.xsd @@ -0,0 +1,50 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Account_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Account object is intended to characterize generic accounts. + + + + + The AccountObjectType type is intended to characterize generic accounts. + + + + + + + The Description property is used for providing a description of the account, if applicable. + + + + + The Domain property is used for specifying the domain that the account belongs to. + + + + + + The disabled field specifies whether or not the account is disabled. + + + + + The locked_out field specifies whether or not the account is locked out. + + + + + + diff --git a/stix_validator/schema/cybox/objects/Address_Object.xsd b/stix_validator/schema/cybox/objects/Address_Object.xsd new file mode 100755 index 0000000..e432139 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Address_Object.xsd @@ -0,0 +1,122 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Address_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Address object is intended to specify a cyber address. + + + + + The AddressObjectType is intended to characterize cyber addresses. + + + + + + + The required Address_Value construct specifies the actual value of the address. + + + + + The VLAN_Name property specifies the name of the Virtual LAN to which the address belongs. + + + + + The VLAN_Num property specifies the number of the Virtual LAN to which the address belongs. + + + + + + The category field specifies the address category that is being defined. + + + + + The is_source field specifies if this is a "Source" address + + + + + The is_destination field specifies if this is a "Destination" address + + + + + + + + The CategoryTypeEnum type is an enumeration of address types. + + + + + The asn value specifies an identifier for an Autonomous System Number. + + + + + The atm value specifies an Asynchronous Transfer Mode address. + + + + + The CIDR value specifies an address in Classless Interdomain Routing notation (the IP address and its associated routing prefix). + + + + + The e-mail value specifies an e-mail address. + + + + + The mac value specifies a system's MAC address. + + + + + The IPV4-addr value specifies an IPV4 address. + + + + + + + + + + The IPV4-net-mask value specifies an IPV4 bitwise netmask. + + + + + The IPV4-addr value specifies an IPV6 address. + + + + + + + + + + The IPV6-net-mask value specifies an IPV6 bitwise netmask. + + + + + diff --git a/stix_validator/schema/cybox/objects/Artifact_Object.xsd b/stix_validator/schema/cybox/objects/Artifact_Object.xsd new file mode 100755 index 0000000..0dd39e5 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Artifact_Object.xsd @@ -0,0 +1,206 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Artifact_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Artifact object is intended to encapsulate and convey the content of a Raw Artifact. + + + + + The ArtifactObjectType type is intended to encapsulate and convey the content of a Raw Artifact. + + + + + + + The Hashes field is optional and specifies hashes for the Raw_Artifact content. + + + + + The Packaging field is optional and characterizes packaging layers (e.g. compression, encryption, encoding) applied to the original content to generate the content of the Raw_Artifact field of this Object. The ordering of entries in this sequence implicitly denotes the ordering of packaging layer operations applied. + + + + + + The Raw_Artifact field contains the raw content of a cyber artifact (rather than simply analysis of that artifact). It is conveyed within a string-based field and should be further enclosed in a CDATA section within the string-based field. + + + + + The Raw_Artifact_Reference field contains a reference to an external instance of the raw content of a cyber artifact (rather than simply analysis of that artifact). + + + + + + + The type field specifies the general type of the artifact contained in this Defined Object. + + + + + The content_type field is optional and specifies the Internet Media Type of the artifact contained in this Defined Object. + + + + + The content_type_version field is optional and specifies the content type version of the artifact contained in this Defined Object. + + + + + The suspected_malicious field is optional and conveys whether the content of the Raw_Artifact is believed to be malicoius. + + + + + + + + The RawArtifactType is intended to convey, with minimal characterization, the content of the Raw Artifact itself. + + + + + + + + The PackagingType captures any packaging layers applied to an artifact. + + + + + + The Compression field is optional and specifies details for a compression layer applied to the content of the Raw_Artifact. + + + + + The Encryption field is optional and specifies details for an encryption layer applied to the content of the Raw_Artifact. + + + + + The Encoding field is optional and specifies details for an encoding layer applied to the content of the Raw_Artifact. + + + + + + + The is_encrypted field is optional and specifies whether the Raw_Artifact content is protected/encrypted. + + + + + The is_compressed field is optional and specifies whether the Raw_Artifact content is compressed. + + + + + + The CompressionType captures any compression packaging details for an artifact. + + + + The compression_mechanism field is optional and specifies the compression algorithm utilized to protect the Raw_Artifact content. + + + + + The compression_mechanism_ref field is optional and conveys a reference to a description of the compression algorithm utilized to protect the Raw_Artifact content. + + + + + + The EncryptionType captures any encryption packaging details for an artifact. + + + + The encryption_mechanism field is optional and specifies the protection/encryption algorithm utilized to protect the Raw_Artifact content. + + + + + The encryption_mechanism_ref field is optional and conveys a reference to a description of the protection/encryption algorithm utilized to protect the Raw_Artifact content. + + + + + The encryption_key field is optional and locally specifies the password for unprotecting/decrypting the Raw_Artifact content. + + + + + The encryption_key_ref field is optional and specifies a reference to a remote specification of the password for unprotecting/decrypting the Raw_Artifact content. + + + + + + The EncodingType captures any encoding packaging details for an artifact. + + + + The algorithm field is optional and specifies the encoding algorithm utilized to encode the Raw_Artifact. + + + + + The character_set field is optional and specifies the character set utilized in the Raw_Artifact content encoding. + + + + + The custom_character_set_ref field is optional and conveys a reference to a specification of the custom character set used to encode the Raw_Artifact. + + + + + + The ArtifactTypeEnum is a (non-exhaustive) enumeration of cyber raw artifact types. + + + + + The File value specifies that the artifact is a file. + + + + + The Memory Region value specifies that the artifact is a block of data from a region of memory. + + + + + The File System Fragment value specifies that the artifact is a block of data from a file system. + + + + + The Network Traffic value specifies that the artifact is a block of network traffic data such as PCAP. + + + + + The Generic Data Region value specifies that the artifact is a block of data from an unknown source. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Code_Object.xsd b/stix_validator/schema/cybox/objects/Code_Object.xsd new file mode 100755 index 0000000..e174d49 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Code_Object.xsd @@ -0,0 +1,417 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Code_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Code object is intended to characterize a body of computer code. + + + + + The CodeObjectType type is intended to characterize a body of computer code. + + + + + + + The Description field is intended for use in providing a brief description of the code that is encapsulated in this field. + + + + + The type field is intended to provide a way of specifying the type of code being characterized. + + + + + The type field is intended to provide a way of specifying the purpose or flavor of code being characterized. + + + + + The code_language field refers to the code language used in the code characterized in this field. + + + + + The Targeted_Platforms field specifies a list platforms that this code is targeted for. + + + + + The processor_family field specifies the class of processor that the code snippet is targeting. Possible values: x86-32, x86-64, IA-64, PowerPC, ARM, Alpha, SPARC, z/Architecture, eSi-RISC, MIPS, Motorola 68k, Other. + + + + + The Discovery_Method field is intended to characterize the method and/or tool used to discover the code. + + + + + The start_address field can be used to reference the start address of the code, if it was discovered inside a binary. + + + + + The Code_Segment field encompasses any arbitrary code segment in un-encoded (plaintext or binary) format. Code would typically be included here within a CDATA section. + + + + + The Code_Segment_XOR field encompasses any arbitrary code segment. Its contents should contain the actual code segment XORed with the pattern defined in the xorpattern property. This is so that the code contained in the pattern does not trigger IDS, AV, or other signature-based scanners. XOR'd Code would typically be included here within a CDATA section. + + + + + The Digital_Signatures field is optional and captures one or more digital signatures for the code. + + + + + A description of features extracted from this code segment. + + + + + + + + + CodeTypeType specifies types of code, via a union of the CodeTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This field is optional and specifies the expected type for the value of the specified field. + + + + + + + + Used to encapsulate a segment of code that has been XORed with a pattern in order to avoid tripping anti-virus detection. + + + + + + The xor_pattern field contains a 16-hexadecimal-character hex string, which represents the pattern that the Code_Segment_XOR field should be XORed with in order to recover the actual code. The default value is 55AA55AA55AA55BB, as specified by IETF RFC 5901. + + + + + + + + CodeTypeEnum is a (non-exhaustive) enumeration of code types. + + + + + The code represented is in the form of Source Code + + + + + The code represented is in the form of Byte Code + + + + + The code represented is in the form of Binar Code + + + + + + + CodePurposeType specifies intended purposes of code, via a union of the CodePurposeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This field is optional and specifies the expected type for the value of the specified field. + + + + + + + + CodePurposeEnum is a (non-exhaustive) enumeration of classes of code intended purposes. + + + + + The code represented is intended as application code. + + + + + The code represented is intended as library code. + + + + + The code represented is intended as shell code. + + + + + The code represented is intended as exploit code. + + + + + The code represented is intended for unknown purposes. + + + + + The code represented is intended for a purpose other than thos listed in this enumeration. + + + + + + + CodeLanguageType specifies languages of code, via a union of the CodeLanguageEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This field is optional and specifies the expected type for the value of the specified field. + + + + + + + + The CodeLanguageEnum simple type is an (non-exhaustive) enumeration of computer code languages. + + + + + Indicates the code is written in the C programming language + + + + + Indicates the code is written in the C++ programming language + + + + + Indicates the code is written in the C# programming language + + + + + Indicates the code is written in the Java programming language + + + + + Indicates the code is written in the JSP (Java Server Pages) language + + + + + Indicates the code is written in the Javascript programming language + + + + + Indicates the code is written in the ASP.NET programming language + + + + + Indicates the code is written in SQL (Standard Query Language) + + + + + Indicates the code is written in the Python programming language + + + + + Indicates the code is written in the Perl programming language + + + + + Indicates the code is written in the PHP programming language + + + + + Indicates the code is written as a SOAP message + + + + + Indicates the code is written in the Ruby programming language + + + + + Indicates the code is written as a Shell script + + + + + Indicates the code is written as psuedo code + + + + + Indicates the code utilizes the .NET framework + + + + + Indicates the code is written in an assembly language + + + + + Indicates the code is written in XML (eXtensible Markup Language) + + + + + Indicates the code is written in HTML (HyperText Markup Language) + + + + + Indicates the code is written in a language not found in this enumeration + + + + + + + ProcessorTypeType specifies relevant processor families, via a union of the ProcessorTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The ProcessorTypeEnum simple type is an (non-exhaustive) enumeration of computer processor architectures. + + + + + Indicates a x86 32bit processor + + + + + Indicates a x86 64bit processor + + + + + Indicates an IA (Intel Itanium) 64bit processor + + + + + Indicates a PowerPC processor + + + + + Indicates an ARM processor + + + + + Indicates an Alpha processor + + + + + Indicates a SPARC processor + + + + + Indicates a z/Architecture (IBM) processor + + + + + Indicates an eSi-RISC processor + + + + + Indicates a MIPS processor + + + + + Indicates a Motorola 68k processor + + + + + Indicates a processor outside of this enumeration + + + + + + + A list of targeted platforms + + + + + The Targeted_Platform field specifies a particular platform that this code is targeted for. + + + + + diff --git a/stix_validator/schema/cybox/objects/Custom_Object.xsd b/stix_validator/schema/cybox/objects/Custom_Object.xsd new file mode 100755 index 0000000..a8838bf --- /dev/null +++ b/stix_validator/schema/cybox/objects/Custom_Object.xsd @@ -0,0 +1,43 @@ + + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Custom_Object + 1.0 + 04/01/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Custom object is intended to characterize objects that are not described by other defined CybOX Object schemas. Objects of this type have no pre-defined properties but instead all properties are provided by the author.. + + + + + + The CustomObjectType is intended to characterize objects that are not described by other defined CybOX Object schemas. Objects of this type have no pre-defined properties but instead all properties are provided by the author using the inherited Custom_Properties field. + + + + + + + A description of the intent of this Custom object. + + + + + + The custom_name field specifies a name for this for this type of Custom Object. The custom_name field should use the same namespace as used in the Object and Observable id fields for this author. Two Objects should only have the same custom_name value if they are written by the same author (i.e., their namespace is the same) and they are characterizing the same type of Object. Note that this does not necessarily mean that that two such Object instances will both have identical properties in every case. + + + + + + diff --git a/stix_validator/schema/cybox/objects/DNS_Cache_Object.xsd b/stix_validator/schema/cybox/objects/DNS_Cache_Object.xsd new file mode 100755 index 0000000..b2ad4ec --- /dev/null +++ b/stix_validator/schema/cybox/objects/DNS_Cache_Object.xsd @@ -0,0 +1,53 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + DNS_Cache_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The DNS_Cache object is intended to characterize a domain name system cache. + + + + + The DNSCacheObjectType type is intended to characterize entries in a system's DNS cache. + + + + + + + The DNS_Cache_Entry field is intended to characterize a single domain name system cache entry. + + + + + + + + + The DNSCacheEntryType type is intended to characterize a single entry in a system's DNS cache. + + + + + The DNS_Entry field specifies the relevant DNS entry (including Domain Name and IP Address) for this DNS Cache Entry. + + + + + The TTL field specifies the time-to-live value for the DNS cache entry, or in other words the number of seconds before the entry expires. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/DNS_Query_Object.xsd b/stix_validator/schema/cybox/objects/DNS_Query_Object.xsd new file mode 100755 index 0000000..551cee1 --- /dev/null +++ b/stix_validator/schema/cybox/objects/DNS_Query_Object.xsd @@ -0,0 +1,159 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + DNS_Query_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + The DNS_Query object is intended to represent a single DNS query. + + + + + The DNSQueryType is intended to characterize a single DNS query and its components. + + + + + + + The Question field specifies the DNS question component of the DNS query. + + + + + The Answers field specifies any Answers resource records that were returned for the DNS query. + + + + + The Authority_Resource_Records field specifies any Authority resource records that were returned for the DNS query. + + + + + The Authority_Resource_Records field specifies any Additional resource records that were returned for the DNS query. + + + + + The Date_Ran field specifies the date and time that the DNS query was run. + + + + + The Service_Used field specifies the service used to run the DNS Query. + + + + + + The successful field specifies whether or not the DNS Query was successful. + + + + + + + + The DNSQuestionType specifies the components of a DNS Question, including the domain name queried, type, and class. + + + + + The QName field specifies the domain name being queried. + + + + + The QType specifies the type of DNS query performed, in terms of the requested DNS record type. + + + + + The QClass field specifies the class of resource records being requested. + + + + + + + The DNSAnswersType encompasses one or more resource records returned for a DNS query. + + + + + The Answer field specifies a single DNS resource record returned as part of a DNS query. + + + + + + + DNSRecordType specifies DNS record types, via a union of the DNSRecordTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The DNSRecordTypeEnum is a non-exhaustive enumeration of DNS Record Type names. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/stix_validator/schema/cybox/objects/DNS_Record_Object.xsd b/stix_validator/schema/cybox/objects/DNS_Record_Object.xsd new file mode 100755 index 0000000..24829ac --- /dev/null +++ b/stix_validator/schema/cybox/objects/DNS_Record_Object.xsd @@ -0,0 +1,87 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + DNS_Record_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + The DNS object is intended to characterize an individual DNS record. + + + + + The DNSRecordObjectType type is intended to characterize an individual DNS record. + + + + + + + The Description field provides a mechanism to specify a structured text description of this DNS_Entry. + + + + + The Domain_Name field specifies the name of the domain to which the DNS cache entry points. + + + + + The IP_Address field specifies the IP address to which the domain name in the DNS cache entry resolves to. + + + + + The Address_Class field specifies the address class (e.g. IN, TXT, ANY, etc.) for the DNS record + + + + + The Entry_Type field specifies the resource record type (e.g. SOA or A) for the DNS record. + + + + + The Record_Name field is optional and specifies the name for the DNS record. + + + + + The Record_Type field is optional and specifies the type of the DNS record. + + + + + The TTL field is optional and specifies the time-to-live for the DNS record. + + + + + The Flags field is optional and specifies the relevant flags for the DNS record. + + + + + The Data_Length field is optional and specifies the length of raw data to be captured in the Record_Data field. + + + + + The Record_Data field is optional and enables capture and expression of the raw record data. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Device_Object.xsd b/stix_validator/schema/cybox/objects/Device_Object.xsd new file mode 100755 index 0000000..bddb4b3 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Device_Object.xsd @@ -0,0 +1,55 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Device_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Device_Object object is intended to characterize a specific Device. + + + + + The DeviceObjectType type is intended to characterize a specific Device. + + + + + + + The Description field is intended for use in providing a brief description of the Device. + + + + + The Device_Type field specifies the type of the device. + + + + + The Manufacturer field specifies the manufacturer of the device. + + + + + The Model field specifies the model identifier of the device. + + + + + The Serial_Number field specifies the serial number of the Device. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Disk_Object.xsd b/stix_validator/schema/cybox/objects/Disk_Object.xsd new file mode 100755 index 0000000..d119930 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Disk_Object.xsd @@ -0,0 +1,117 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Disk_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Disk object is intended to characterize a disk drive. + + + + + The DiskObjectType type is intended to characterize disk drives. + + + + + + + The Disk_Name field specifies the name of the disk. + + + + + The Disk_Size field specifies the size of the disk, in bytes. + + + + + The Free_Space field specifies the amount of free space on the disk, in bytes. + + + + + The Partition_List field specifies the partitions that reside on the disk. + + + + + The Type field specifies the type of disk being characterized, e.g. removable. + + + + + + + + + The PartionListType type specifies a list of partitions. + + + + + The Partition field specifies a single partition that resides on the disk. + + + + + + + DiskType specifies disk types, via a union of the DiskTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The DiskTypeEnum type contains a non-exhaustive enumeration of disk types. + + + + + Indicates the removable disk type. + + + + + Indicates the fixed disk type. + + + + + Indicates the remote disk type. + + + + + Indicates the CDRom disk type. + + + + + Indicates the RAMDisk disk type. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Disk_Partition_Object.xsd b/stix_validator/schema/cybox/objects/Disk_Partition_Object.xsd new file mode 100755 index 0000000..0022cad --- /dev/null +++ b/stix_validator/schema/cybox/objects/Disk_Partition_Object.xsd @@ -0,0 +1,199 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Disk_Partition_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Disk_Partition object is intended to characterize a single partition of a disk drive. + + + + + The DiskPartitionType type is intended to characterize partitions of disk drives. + + + + + + + The Created field specifies the date/time the partition was created. + + + + + The Device_Name field specifies the name of the device on which the partition resides. + + + + + The Mount_Point field specifies the mount point of the partition. + + + + + The Partition_ID field specifies the numerical identifier of the partition. + + + + + The Partition_Length field specifies the length of the partition, in bytes. + + + + + The Partition_Offset field specifies the starting offset of the partition, in bytes. + + + + + The Space_Left field specifies the amount of space left on the partition, in bytes. + + + + + The Space_Used field specifies the amount of space used on the partition, in bytes. + + + + + The Total_Space field specifies the total amount of space available on the partition, in bytes. + + + + + The Type field specifies the type of partition being characterized. + + + + + + + + + PartitionType specifies partition types, via a union of the PartitionTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The PartitionTypeEnum type is a non-exhaustive enumeration of partition types. See http://www.win.tue.nl/~aeb/partitions/partition_types-1.html for more information about the various partition types. + + + + + Indicates an unused partition entry. + + + + + Indicates a FAT 12 partition. + + + + + Indicates a XENIX type 1 partition. + + + + + Indicates a XENIX type 2 partition. + + + + + Indicates a XENIX FAT 16 partition. + + + + + Indicates a XENIX extended partition. + + + + + Specifies an MS-DOS V4 huge partition. This value indicates that there is no Microsoft file system on the partition. Use this value when creating a logical volume. + + + + + Indicates an IFS partition. + + + + + Indicates an OS/2 boot manager partition. + + + + + Indicates a FAT32 partition. + + + + + Indicates a FAT32 Extended-INT13 equivalent partition to the FAT32 partition. + + + + + Indicates an XINT13 partition. + + + + + Indicates an extended XINT13 partition. + + + + + Indicates a PReP (Power PC Reference Platform) partition. + + + + + Indicates an LDM partition. + + + + + Indicates a UNIX partition. + + + + + Specifies a valid NTFT partition. The high bit of a partition type code indicates that a partition is part of an NTFT mirror or striped array. + + + + + Specifies an NTFT partition. + + + + + Refers to an unknown partition or a partition other than those listed. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Email_Message_Object.xsd b/stix_validator/schema/cybox/objects/Email_Message_Object.xsd new file mode 100755 index 0000000..a6dd7b8 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Email_Message_Object.xsd @@ -0,0 +1,273 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Email_Message_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Email_Message object is intended to characterize an individual email message. + + + + + The EmailMessageObjectType type is intended to characterize an individual email message. + + + + + + + The Header field specifies a variety of common headers that may be included in the email message. + + + + + The Email_Server field is optional and specifies the relevant email server. + + + + + The Raw_Body field specifies the complete (raw) body of the email message. + + + + + The Raw_Header field specifies the complete (raw) headers of the email message. + + + + + The Attachments field specifies any files that were attached to the email message. It imports and uses the CybOX FileObjectType from the File_Object to do so. + + + + + The Links field specifies any URL links contained within the email message. It imports and uses the CybOX URIObjectType from the URI_Object to do so. + + + + + + + + + The AttachmenstType captures a list of attachments for an email message. + + + + + The File field specifies a file that was attached to the email message, via a reference to an Object included elsewhere in the document. + + + + + + + The EmailHeaderType captures a representation of a standard email header. + + + + + The Received_Lines field specifies one or more 'Received' lines that may be included in the email header. + + + + + The To field specifies the email addresses of the recipients of the email message. + + + + + The CC field specifies the email addresses of any recipients that were included in the carbon copy header of the email message. + + + + + The BCC field specifies the email addresses of any recipients that were included in the blind carbon copy header of the email message. + + + + + The From field specifies the email address of the sender of the email message. + + + + + The Subject field specifies the subject (a brief summary of the message topic) of the email message. + + + + + The In_Reply_To field specifies the message ID of the message that this email is a reply to. + + + + + The Date field specifies the date/time that the email message was sent. + + + + + The Message_ID field specifies the automatically generated ID of the email message. + + + + + The Sender field specifies the email address of the sender who is acting on behalf of the author listed in the From: field. + + + + + The Reply_To field specifies the email address that should be used when replying to the email message. + + + + + The Errors_To field specifies the entry in the (deprecated) errors_to header of the email message. + + + + + The Boundary field specifies a boundary tag that may be included in a MIME multipart message. This boundary tag is used to indicate the parts of a multipart message. + + + + + The Content-Type field specifies the internet media, or MIME, type of the email message content. + + + + + The MIME-Version field specifies the version of the MIME formatting used in the email message. + + + + + The Precedence field specifies the (non-standard) priority value of the message, which can influence transmission speed and delivery. Use of this field is typically discouraged, as per IETF RFC2076 (http://www.faqs.org/rfcs/rfc2076.html). + + + + + The User-Agent field specifies the identity of the email user agent software that may have been used to send the email message. + + + + + The X-Mailer field specifies the software used to send the email message. This field is non-standard. + + + + + The X-Originating-IP field specifies the originating IP Address of the email sender, in terms of their connection to the mail server used to send the email message. This field is non-standard. + + + + + The X-Priority field specifies the numerical priority of the email message. This is a non-standard field, but typically a value of '1' is considered the highest priority, '3' is normal, and '5' is the lowest priority. + + + + + + + The EmailRecipientsType captures a list of recipients for an email message. + + + + + The Recipient field represents a single recipient for an email message. + + + + + + + The LinksType captures a list of URIs, representing the links contained in the message. + + + + + The Link field specifies a single URL link contained within the email message, via a reference to an Object included elsewhere in the document. + + + + + + + The EmailReceivedLineType captures a single 'Received' line in an email message header. + + + + + The From field captures the 'from' portion of the Received line, if applicable. + + + + + The By field captures the 'by' portion of the Received line, if applicable. + + + + + The With field captures the 'with' portion of the Received line, if applicable. + + + + + The For field captures the 'for' portion of the Received line, if applicable. + + + + + The ID field captures the 'id' portion of the Received line, if applicable. + + + + + The Timestamp field captures the timestamp portion of the Received line, if applicable. + + + + + + + The EmailReceivedLineListType captures a list of 'Received' lines in an email message header. + + + + + The Received field captures a single Received line in the list. + + + + + + + The AttachmentReferenceType specifies a reference to an Object defined elsewhere in the document which characterizes an attachment included in the email message. + + + + The object_reference field specifies a reference to an file-oriented (i.e., the File Object or one its derivations such as the Windows File Object) Object defined elsewhere in the document, via its id. + + + + + + The LinkReferenceType specifies a reference to a URI Object defined elsewhere in the document which characterizes a hyperlink embedded in the body of the email message. + + + + The object_reference field specifies a reference to a URI Object defined elsewhere in the document, via its id. + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/File_Object.xsd b/stix_validator/schema/cybox/objects/File_Object.xsd new file mode 100755 index 0000000..1389513 --- /dev/null +++ b/stix_validator/schema/cybox/objects/File_Object.xsd @@ -0,0 +1,359 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + File_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The File object is intended to characterize a generic file. + + + + + The File_ObjectType type is intended to characterize generic files. + + + + + + + The File_Name field specifies the name of the file. + + + + + The File_Path field specifies the path to the file, not including the device. Whether the path is relative or fully-qualified can be specified via the 'fully_qualified' attribute of this property. + + + + + The Device_Path field specifies the path to the device on which the file resides. + + + + + The Full_Path field specifies the complete path to the file, including the device path. + + + + + The File_Extension field specifies the file extension of the file. + + + + + The Size_In_Bytes field specifies the size of the file, in bytes. + + + + + The Magic_Number specifies the particular magic number (typically a hexadecimal constant used to identify a file format) corresponding to the file, if applicable. + + + + + The File_Format field specifies the particular file format of the file, most typically specified by a tool such as the UNIX file command. + + + + + The Hashes field specifies any hashes of the file. + + + + + The Digital_Signatures field is optional and captures one or more digital signatures for the file. + + + + + The Modified_Time field specifies the date/time the file was last modified. + + + + + The Accessed_Time field specifies the date/time the file was last accessed. + + + + + The Created_Time field specifies the date/time the file was created. + + + + + The File_Attributes_List field specifies the particular special attributes set for the file. Since this is a platform-specific Object property, it is defined here as an abstract type and then implemented in any platform specific derived file objects. + + + + + The Permissions field specifies that particular permissions that a file may have. Since this is a platform-specific Object property, it is defined here as an abstract type and then implemented in any platform specific derived file objects. + + + + + The User_Owner field specifies the name of the user that owns the file. + + + + + The Packer_List field specifies any packers that the file may be packed with. The term 'packer' here refers to packers, as well as things like archivers and installers. + + + + + The Peak_Entropy field specifies the calculated peak entropy of the file. + + + + + The Sym_Links field specifies any symbolic links that may exist for the file. + + + + + The Byte_Runs field contains a list of byte runs from the raw file or its storage medium. + + + + + A description of features extracted from this file. + + + + + + The ispacked field is used to indicate whether the file is packed or not. + + + + + + + + The FilePathType type specifies the path to the file, not including the device. Whether the path is relative or fully-qualified can be specified via the 'fully_qualified' attribute. + + + + + + The fully_qualified field specifies whether the path is fully qualified. + + + + + + + + The FileAttributeType type specifies attribute(s) of a file. Since this Object property(ies) is platform-specific, it is defined here as an abstract type. + + + + + The FilePermissionsType type specifies a permission of a file. Since this is a platform-specific Object property, it is defined here as an abstract type and then implemented in any platform specific derived file objects. + + + + + The PackerListType type specifies a list of file packers. + + + + + The Packer field specifies a single file packer. + + + + + + + The PackerType specifies the fields that characterize a particular file packer, such as name and version. + + + + + The Name field specifies the name of the packer. + + + + + The Version field specifies the version of the packer. + + + + + The Entry_Point field specifies the entry point address of the packer, if applicable. + + + + + The Signature field specifies the matching signature detected for the packer, if applicable. + + + + + The Type field specifies the type of packer being characterized. + + + + + The Detected_Entrypoint_Signatures field specifies the entrypoint signatures that were detected for the packer. + + + + + The EP_Jump_Codes field characterizes the entry point jump codes of the packer. + + + + + + + PackerCassType specifies packer classes, via a union of the PackerTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This field is optional and specifies the expected type for the value of the specified field. + + + + + + + + Specifies an entry-point jump code used by a packer. + + + + + + + + + Specifies an entry point signature for a packer. + + + + + Specifies the signature name. + + + + + Specifies the type of entry point detected (e.g., packer, compiled file). + + + + + + + The DetectedTypeEnum is an enumeration of entry point signature detection types. + + + + + Specifies a type other than those listed. + + + + + Specifies an executable that acts as a compiler. + + + + + Specifies an executable that acts as a packer. + + + + + Specifies an executable that acts as an installer. + + + + + + + Species a list of entry point signatures for a packer. + + + + + Specifies a single field in a list of entry point signatures. + + + + + + + The PackerTypeEnum type is a (non-exhaustive) enumeration of packer classes. + + + + + Indicates that the packer is an archiver. + + + + + Indicates that the packer is an installer. + + + + + Indicates that the packer is a self-extracting archiver. + + + + + Indicates that the packer is a crypter. + + + + + Indicates a packer. + + + + + Indicates that the packer is a protector. + + + + + Indicates that the packer is a bundler. + + + + + Indicates a different type of packer from the ones listed. + + + + + + + The SymLinksListType specifies a list of symbolic links. + + + + + The Sym_Link element specifies a single symbolic link. + + + + + diff --git a/stix_validator/schema/cybox/objects/GUI_Dialogbox_Object.xsd b/stix_validator/schema/cybox/objects/GUI_Dialogbox_Object.xsd new file mode 100755 index 0000000..b3ace6f --- /dev/null +++ b/stix_validator/schema/cybox/objects/GUI_Dialogbox_Object.xsd @@ -0,0 +1,41 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + GUI_Dialogbox_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The GUI_Dialogbox object is intended to characterize GUI dialog boxes. + + + + + The GUIDialogboxObjectType type is intended to characterize GUI dialog boxes. + + + + + + + The Box_Caption field specifies the caption associated with the dialog box. + + + + + The Box_Text field specifies the text contained inside the dialog box. + + + + + + + diff --git a/stix_validator/schema/cybox/objects/GUI_Object.xsd b/stix_validator/schema/cybox/objects/GUI_Object.xsd new file mode 100755 index 0000000..4892070 --- /dev/null +++ b/stix_validator/schema/cybox/objects/GUI_Object.xsd @@ -0,0 +1,40 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + GUI_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The GUI_Object object is intended to charaterize generic GUI objects. + + + + + The GUIObjectType type is intended to characterize generic GUI objects. + + + + + + + The Height field specifices the height of the GUI object. + + + + + The Width field specifies the width of the GUI object. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/GUI_Window_Object.xsd b/stix_validator/schema/cybox/objects/GUI_Window_Object.xsd new file mode 100755 index 0000000..539ae56 --- /dev/null +++ b/stix_validator/schema/cybox/objects/GUI_Window_Object.xsd @@ -0,0 +1,46 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + GUI_Window_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The GUI_Window object is intended to characterize GUI windows. + + + + + The GUIWindowObjectType is intended to characterize GUI windows. + + + + + + + The Owner_Window specifies the owner window of the window object. + + + + + The Parent_Window field contains the parent window of the window object. + + + + + The Window_Display_Name field specifies the display name or title bar text of the window object. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/HTTP_Session_Object.xsd b/stix_validator/schema/cybox/objects/HTTP_Session_Object.xsd new file mode 100755 index 0000000..2087464 --- /dev/null +++ b/stix_validator/schema/cybox/objects/HTTP_Session_Object.xsd @@ -0,0 +1,623 @@ + + + + This schema was originally developed by [NAME] at [COMPANY]. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + HTTP_Session_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + + The HTTP_Session object is intended to capture the HTTP requests and responses made on a single HTTP session. + + + + + The HTTPSessionObjectType is intended to capture the details of an HTTP session. + + + + + + + The HTTP_Request_Response field specifies a single HTTP Request/Response pair. + + + + + + + + + The HTTPRequestResponseType captures a single HTTP request/response pair. + + + + + The HTTP_Client_Request field specifies the HTTP client request portion of a single HTTP request/response pair. + + + + + The HTTP_Server_Response field specifies the HTTP server response portion of a single HTTP request/response pair. + + + + + + + The HTTPClientRequestType field captures the details of an HTTP client request. + + + + + The HTTP_Request_Line field specifies the HTTP request line of the HTTP client request. + + + + + The HTTP_Request_Header field specifies all of the HTTP header fields that may be found in the HTTP client request. + + + + + The HTTP_Message_Body field specifies the optional message body that may be included in the HTTP client request. + + + + + + + The HTTPServerResponseType captures the details of an HTTP server response. + + + + + The HTTP_Status_Line field captures the status line returned as part of the HTTP server response. + + + + + The HTTP_Response_Header field captures the details of the HTTP Header returned as part of the HTTP server response. + + + + + The HTTP_Message_Body field captures the HTTP message body returned as part of the HTTP server response. + + + + + + + The HTTPRequestLineType captures a single HTTP request line. + + + + + The HTTP_Method field captures the HTTP method portion of the HTTP request line. + + + + + The Value field captures the value (typically a resource path) portion of the HTTP request line. + + + + + The Version field captures the HTTP version portion of the HTTP request line. + + + + + + + The HTTPRequestHeaderType captures the raw or parsed header of an HTTP request. + + + + + The Raw_Header field captures the HTTP request header as a raw, un-parsed string. + + + + + The Parsed_Header field captures the HTTP request header as a set of parsed HTTP header fields. + + + + + + + The HTTPRequestHeaderFieldsType captures parsed HTTP request header fields. + + + + + The Accept field specifies the HTTP Request Accept header field, which defines the Content-Types that are acceptable. + + + + + The Accept-Charset field specifies the HTTP Request Accept-Charset header field, which defines the character sets that are acceptable. + + + + + The Accept-Language field specifies the HTTP Request Accept-Language header field, which defines the acceptable languages for response. + + + + + The Accept-Datetime field specifies the HTTP Request Accept-Datetime header field, which defines the acceptable version time. + + + + + The Accept-Encoding field specifies the HTTP Request Accept-Encoding header field, which defines the acceptable encodings. + + + + + The Authorization field specifies the HTTP Request Authorization header field, which defines the authentication credentials for use in HTTP authentication. + + + + + The Cache-Control field specifies the HTTP Request Cache-Control header field, which defines the directives that MUST be obeyed by all caching mechanisms along the request/response chain. + + + + + The Connection field specifies the HTTP Request Connection header field, which defines the type of connection that the user-agent would prefer. + + + + + The Cookie field specifies the HTTP Request Cookie header field, which defines the HTTP cookie previously sent by the server. + + + + + The Content-Length field specifies the HTTP Request Content-Length header field, which defines the length of the request body in octets. + + + + + The Content-MD5 field specifies the HTTP Request Content-MD5 header field, which defines a Base64 encoded binary MD5 sum of the content of the request body. + + + + + The Content-Type field specifies the HTTP Request Content-Type header field, which defines a the MIME type of the body of the request (used with POST and PUT requests). + + + + + The Date field specifies the HTTP Request Date header field, which defines the date and time that the message was sent. + + + + + The Expect field specifies the HTTP Request Expect header field, which defines the particular server behaviors that are required by the client. + + + + + The From field specifies the HTTP Request From header field, which defines the email address of the user making the request. + + + + + The Host field specifies the HTTP Request Host header field, which the domain name of the server and the TCP port number on which the server is listening. + + + + + The If-Match field specifies the HTTP Request If-Match header field, which allows the action to be performed if the client supplied entity matches the same entity on the server. + + + + + The If-Modified-Since field specifies the HTTP Request If-Modified-Since header field, which allows a 304 Not Modified response to be returned if content is unchanged since the input date/time. + + + + + The If-Modified-Since field specifies the HTTP Request If-Modified-Since header field, which allows the action to be performed only if the client supplied entity does not match the same entity on the server. + + + + + The If-Range field specifies the HTTP Request If-Range header field, which allows the client to request the part(s) of the entity that they are missing, or otherwise the new entity. + + + + + The If-Unmodified-Since field specifies the HTTP Request If-Unmodified-Since header field, which allows a response to be sent only if the entity has not been modified since a specific date/time. + + + + + The Max-Forwards field specifies the HTTP Request Max-Forwards header field, which defines the maximum number of times the message can be forwarded through proxies or gateways. + + + + + The Pragma field specifies the HTTP Request Pragma header field, which defines any implementation-specific values that may have various anywhere along the request-response chain. + + + + + The Proxy-Authorization field specifies the HTTP Request Proxy-Authorization header field, which defines the authorization credentials for connecting to a proxy. + + + + + The Range field specifies the HTTP Request Range header field, which defines the range, in bytes, for requesting only part of an entity (bytes are numbered from 0). + + + + + The Referer field specifies the HTTP Request Range Referer field, which defines the address of the previous web page from which a link to the currently requested page was followed. + + + + + The TE field specifies the HTTP Request TE field, which defines the transfer encodings the user agent is willing to accept. + + + + + The User-Agent field specifies the HTTP Request User-Agent field, which defines the user agent string of the user agent. + + + + + The Via field specifies the HTTP Request Via field, which defines any proxies through which the request was sent. + + + + + The Warning field specifies the HTTP Request Warning field, which defines any general warnings about possible problems with the entity body. + + + + + The DNT field specifies the non-standard HTTP Request DNT field, which is typically used to request that a web application disable their tracking of a user. + + + + + The X-Requested-With field specifies the non-standard HTTP Request X-Requested-With field, which is typically used to identify Ajax requests. + + + + + The X-Forwarded-For field specifies the non-standard HTTP Request X-Forwarded-For field, which is typically used to identify the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer. + + + + + The X-ATT-DeviceId field specifies the non-standard HTTP Request X-ATT-DeviceId field, which is typically used to identify the make, model, and firmware of AT&T devices. + + + + + The X-Wap-Profile field specifies the non-standard HTTP Request X-Wap-Profile field, which is typically used to link to an XML file on the Internet with a full description and details about the device currently connecting. + + + + + + + The HTTPResponseHeaderType captures the raw or parsed header of an HTTP response. + + + + + The Raw_Header field captures the HTTP response header as a raw, un-parsed string. + + + + + The Parsed_Header field captures the HTTP response header as a set of parsed HTTP header fields. + + + + + + + The HTTPRequestHeaderFieldsType captures parsed HTTP request header fields. + + + + + The Access-Control-Allow-Origin field specifies the HTTP Response Access-Control-Allow-Origin header field, which defines which web sites can participate in cross-origin resource sharing. + + + + + The Accept-Ranges field specifies the HTTP Response Accept-Ranges header field, which defines the partial content range types this server supports. + + + + + The Age field specifies the HTTP Response Authorization header field, which defines the age the object has been in a proxy cache, in seconds. + + + + + The Cache-Control field specifies the HTTP Response Cache-Control header field, which tells all caching mechanisms from server to client whether they may cache this object. + + + + + The Connection field specifies the HTTP Response Connection header field, which specifies the options that are desired for the connection. + + + + + The Content-Encoding field specifies the HTTP Response Content-Encoding header field, which defines the type of encoding used on the data. + + + + + The Content-Language field specifies the HTTP Response Content-Language header field, which defines the language the content is in. + + + + + The Content-Length field specifies the HTTP Response Content-Length header field, which defines the length of the request body in octets. + + + + + The Content-Location field specifies the HTTP Response Content-Location header field, which defines an alternate location for the returned data. + + + + + The Content-MD5 field specifies the HTTP Response Content-MD5 header field, which defines the base64-encoded binary MD5 sum of the content of the response. + + + + + The Content-Disposition field specifies the HTTP Response Content-Disposition header field, which provides a means for the origin server to suggest a default filename if the user requests that the content is saved to a file. + + + + + The Content-Range field specifies the HTTP Response Content-Range header field, which defines where in a full body message the partial message belongs. + + + + + The Content-Type field specifies the HTTP Response Content-Type header field, which defines the MIME type of the content. + + + + + The Date field specifies the HTTP Request Date header field, which defines the date and time that the message was sent. + + + + + The ETag field specifies the HTTP Response ETag header field, which defines an identifier for a specific version of a resource, often a message digest. + + + + + The Expires field specifies the HTTP Response Expires header field, which defines the date/time after which the response is considered stale. + + + + + The Last-Modified field specifies the HTTP Response Last-Modified header field, which defines the date/time for the requested object, in RFC 2822 format. + + + + + The Link field specifies the HTTP Response Link header field, which defines a typed relationship with another resource, where the relation type is defined by RFC 5988. + + + + + The Location field specifies the HTTP Response Location header field, which defines the location used in redirection, or when a new resource has been created. + + + + + The P3P field specifies the HTTP Response P3P header field, which sets P3P policy to be used by the browser. + + + + + The Pragma field specifies the HTTP Response Pragma header field, which defines any implementation-specific values that may have various anywhere along the request-response chain. + + + + + The Proxy-Authenticate field specifies the HTTP Response Proxy-Authenticate header field, which defines the type of authentication necessary to access the proxy. + + + + + The Refresh field specifies the HTTP Response Refresh header field, which specifies a given interval, in seconds, after which the current page should be refreshed. + + + + + The Retry-After field specifies the HTTP Response Retry-After header field, which defines the period, in seconds, after which the client should try again if an entity is temporarily unavailable. + + + + + The Server field specifies the HTTP Response Server field, which defines a name for the responding server. + + + + + The Set-Cookie field specifies the HTTP Response Set-Cookie field, which defines an HTTP cookie. + + + + + The Strict-Transport-Security field specifies the HTTP response Strict-Transport-Security field, which defines the HSTS Policy informing the HTTP client how long to cache the HTTPS only policy and whether this applies to subdomains. + + + + + The Trailer field specifies the HTTP Response Trailer field, which indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer-coding. + + + + + The Transfer-Encoding field specifies the HTTP Response Transfer-Encoding field, which defines the form of encoding used to safely transfer the entity to the user. + + + + + The Vary field specifies the HTTP Response Vary field, which informs downstream proxies on how to match future request headers to decide whether the cached respones can be used rather than requested a fresh one from the origin server. + + + + + The Via field specifies the HTTP Response Via field, which informs the client of proxies through which the response was sent. + + + + + The Warning field specifies the HTTP Response Warning field, which defines any general warnings about possible problems with the entity body. + + + + + The WWW-Authenticate field specifies the HTTP Response WWW-Authenticate field, which defines the authentication scheme that should be used to access the requested entity. + + + + + The X-Frame-Options field specifies the non-standard HTTP Response X-Frame-Options field, which is used as a form of clickjacking protection, supporting no rendering within a frame and no rendering if origin mismatch. + + + + + The X-XSS-Protection field specifies the non-standard HTTP Response X-XSS-Protection field, which is used as a cross-site scripting (XSS) filter. + + + + + The X-Content-Type-Options field specifies the non-standard HTTP Response X-Content-Type-Options field, which supports the 'nosniff' parameter to prevent the MIME-sniffing of a response away from the declared content type. + + + + + The X-Forwarded-Proto field specifies the non-standard HTTP Response X-Forwarded-Proto field, which identifies the originating protocol of an HTTP request. + + + + + The X-Powered-By field specifies the non-standard HTTP Response X-Powered-By field, which specifies the technology supporting the web application running on the server. + + + + + The X-UA-Compatible field specifies the non-standard HTTP Response X-UA-Compatible field, which is used to recommend the preferred rendering engine to use to display the content. + + + + + + + The HTTPMessageType captures a single HTTP message body and its length. + + + + + The Length field captures the length of the HTTP message body, in bytes. + + + + + The Message_Body field captures the data contained in the HTTP message body. + + + + + + + The HTTPStatusLineType captures a single HTTP response status line. + + + + + The Version field captures the HTTP version portion of the HTTP status line. + + + + + The Status_Code field captures the HTTP status code portion of the HTTP status line. + + + + + The Reason_Phrase field captures the HTTP reason phrase portion of the HTTP status line. + + + + + + + The HostFieldType captures the details of the HTTP request Host header field. + + + + + The Domain_Name field specifies the domain name of the server. + + + + + The Port field specifies the TCP port number on which the server is listening. + + + + + + + HTTPMethodType specifies HTTP method types, via a union of the HTTPMethodEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The HTTPMethodEnum is an enumeration of HTTP method types. + + + + + + + + + diff --git a/stix_validator/schema/cybox/objects/Library_Object.xsd b/stix_validator/schema/cybox/objects/Library_Object.xsd new file mode 100755 index 0000000..fc19a0f --- /dev/null +++ b/stix_validator/schema/cybox/objects/Library_Object.xsd @@ -0,0 +1,114 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Library_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Library object is intended to characterize software libraries. + + + + + The LibraryObjectType type is intended to characterize software libraries. + + + + + + + The Name field specifies the full file name of the library. Example: abcd.dll. + + + + + The Path field specifies the fully-qualified path to the library. + + + + + The Size field specifies the size of the library, in bytes. + + + + + The Type field specifies the type of library being characterized. + + + + + The Version field specifies the library version. + + + + + The Base_Address field specifies the default virtual address into which the library is loaded. + + + + + A description of features extracted from this file. + + + + + + + + + LibraryType specifies library types, via a union of the LibraryTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The LibraryTypeEnum type is an enumeration of library types. + + + + + Indicates a dynamic library. + + + + + Indicates a static library. + + + + + Indicates a remote library. + + + + + Indicates a shared library. + + + + + Indicates a different type of library than those listed above. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Link_Object.xsd b/stix_validator/schema/cybox/objects/Link_Object.xsd new file mode 100755 index 0000000..3b9b9b9 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Link_Object.xsd @@ -0,0 +1,24 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Link_Object + 1.0 + 03/27/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + + + + + + + diff --git a/stix_validator/schema/cybox/objects/Linux_Package_Object.xsd b/stix_validator/schema/cybox/objects/Linux_Package_Object.xsd new file mode 100755 index 0000000..cfd4d5f --- /dev/null +++ b/stix_validator/schema/cybox/objects/Linux_Package_Object.xsd @@ -0,0 +1,119 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Linux_Package_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Linux_Package object is intended to characterize a Linux package. + + + + + The LinuxPackageObjectType type is intended to characterize Linux packages. + + + + + + + The Architecture field specifies the architecture for which the package was built. + + + + + The Category field specifies the categories under which a package may be displayed. + + + + + The Description field specifies an in-depth description of a package. + + + + + The Epoch field specifies the epoch number of the package. + + + + + The EVR field specifies the epoch, version, and release fields of the package as a single version string. + + + + + The Name field specifies the name of the package. + + + + + The Release field specifies the release number of the package build. + + + + + The Vendor field specifies the vendor that holds the software copyright of the package. + + + + + The Version field specifies the version number of the package build. + + + + + + + + + ArchitectureType specifies CPU architecture types, via a union of the ArchitectureTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The ArchitectureTypeEnum type is a non-exhaustive enumeration of CPU architectures. + + + + + Indicates an i386 architecture. + + + + + Indicates an PPC architecture. + + + + + Indicates an SPARC architecture. + + + + + Indicates no particular architecture. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Memory_Object.xsd b/stix_validator/schema/cybox/objects/Memory_Object.xsd new file mode 100755 index 0000000..6f69e02 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Memory_Object.xsd @@ -0,0 +1,70 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Memory_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Memory_Region object is intended to characterize generic memory objects. + + + + + The MemoryObjectType type is intended to characterize generic memory objects. + + + + + + + The Hashes field specifies any hashes of the particular memory object. + + + + + The Name field specifies the name of the particular memory object, if applicable. + + + + + The Region_Size field specifies the size of the particular memory region, in bytes. + + + + + The Region_Start_Address field specifies the starting address of the particular memory region. + + + + + A description of features extracted from this memory region. + + + + + + The is_injected field specifies whether or not the particular memory object has had data/code injected into it by another process. + + + + + The is_mapped field specifies whether or not the particular memory object has been assigned a byte-for-byte correlation with some portion of a file or file-like resource. + + + + + The is_protected field specifies whether or not the particular memory object is protected (read/write only from the process that allocated it). + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Mutex_Object.xsd b/stix_validator/schema/cybox/objects/Mutex_Object.xsd new file mode 100755 index 0000000..15aabac --- /dev/null +++ b/stix_validator/schema/cybox/objects/Mutex_Object.xsd @@ -0,0 +1,40 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Mutex_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Mutex object is intended to characterize generic mutual exclusion (mutex) objects. + + + + + The MutexObjectType type is intended to characterize generic mutual exclusion (mutex) objects. + + + + + + + The Name field specifies the name for a named mutex object. + + + + + + The named field specifies whether the Mutex is named. + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Network_Connection_Object.xsd b/stix_validator/schema/cybox/objects/Network_Connection_Object.xsd new file mode 100755 index 0000000..20a17cc --- /dev/null +++ b/stix_validator/schema/cybox/objects/Network_Connection_Object.xsd @@ -0,0 +1,609 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Network_Connection_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + + The Network_Connection object is intended to represent a single network connection. + + + + + The NetworkConnectionObjectType is intended as a way of characterizing local or remote (i.e. Internet) network connections. + + + + + + + The Creation_Time field specifies the date/time the network connection was created. + + + + + The Layer3_Protocol field specifies the particular network (layer 3 in the OSI model) layer protocol used in the connection. + + + + + The Layer4_Protocol field specifies the particular transport (layer 4 in the OSI model) layer protocol used in the connection. + + + + + The Layer7_Protocol field specifies the particular application (layer 7 in the OSI model) layer protocol used in the connection. + + + + + The Source_Socket_Address field specifies the source socket address, consisting of an IP Address and port number, used in the connection. + + + + + The Source_TCP_State field specifies the current state of the TCP network connection at the source, if applicable. + + + + + The Destination_Socket_Address field specifies the destination socket address, consisting of an IP Address and port number, used in the connection. + + + + + The Destination_TCP_State field specifies the current state of the TCP network connection at the destination, if applicable. + + + + + The Layer7_Connections field allows for the characterization of any application (layer 7 in the OSI model) layer connections observed as part of the network connection. + + + + + + The tls_used field specifies whether or not Transport Layer Security (TLS) is used in the network connection. + + + + + + + + The Layer7ConnectionsType specifies the different types of application (layer 7 in the OSI model) connections that may be initiated as part of the network connection. + + + + + The HTTP Session field specifies a single HTTP session initiated between source and destination IP addresses/ports, and includes 1-n HTTP Request/Response pairs. + + + + + The DNS_Query field specifies a single DNS query/answer pair initiated between source and destination IP addresses/ports. + + + + + + + Layer3ProtocolType specifies Layer 3 protocol types, via a union of the Layer3ProtocolEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + Layer4ProtocolType specifies Layer 4 protocol types, via a union of the Layer4ProtocolEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + Layer7ProtocolType specifies Layer 7 protocol types, via a union of the Layer7ProtocolEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The ConnectionStateEnum type is an enumeration of TCP connection states. + + + + + Indicates an unknown TCP connection state. + + + + + Indicates the closed TCP connection state--i.e. no connection state at all. + + + + + Indicates the listening TCP connection state. + + + + + Indicates the SYN sent TCP connection state--i.e. wait for a matching connection request after having sent a connection request. + + + + + Indicates the SYN received TCP connection state--i.e. waiting for a confirming connection request acknowledgment after having both received and sent a connection request. + + + + + Indicates the established TCP connection state--i.e. an open connection in which data received can be delivered to the user. + + + + + Indicates the FIN-WAIT-1 TCP connection state--i.e. waiting for a connection termination request from the remote TCP, or an acknowledgment of the connection termination request previously sent. + + + + + Indicates the FIN-WAIT-2 TCP connection state--i.e. waiting for a connection termination request from the remote TCP. + + + + + Indicates the CLOSE-WAIT TCP connection state--i.e. waiting for a connection termination request from the local user. + + + + + Indicates the CLOSING TCP connection state--i.e. waiting for a connection termination request acknowledgment from the remote TCP. + + + + + Indicates the LAST-ACK connection state--i.e. waiting for an acknowledgment of the connection termination request previously sent to the remote TCP (which includes an acknowledgment of its connection termination request). + + + + + Indicates the TIME-WAIT connection state--i.e. waiting for for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request. + + + + + Indicates the DELETE-TCB connection state--i.e. the Transmission Control Block (TCB) is being deleted. + + + + + + + Layer3ProtocolEnum is a non-exhaustive enumeration of Layer 3 (network) layer protocols. + + + + + Specifies the Internet Protocol, version 4. + + + + + Specifies the Internet Protocol, version 6. + + + + + Specifies the Internet Control Message Protocol. + + + + + Specifies the Internet Group Management Protocol. + + + + + Specifies the Interior Gateway Routing Protocol. + + + + + Specifies the Connectionless Networking Protocol. + + + + + Specifies the Exterior Gateway Protocol. + + + + + Specifies the Enhanced Interior Gateway Routing Protocol. + + + + + Specifies the Internet Protocol Security suite. + + + + + Specifies the Internetwork Packet Exchange protocol + + + + + Specifies the Routed Split Multi-Link Trunking protocol. + + + + + Specifies the Signalling Connection Control Part protocol. + + + + + + + Layer4ProtocolEnum is a non-exhaustive enumeration of Layer 4 (transport) layer protocols. + + + + + Specifies the Transmission Control Protocol. + + + + + Specifies the User Datagram Protocol. + + + + + Specifies the Authentication Header protocol. + + + + + Specifies the Encapsulating Security Payload protocol. + + + + + Specifies the Generic Routing Encapsulation protocol. + + + + + Specifies the Internet Link protocol. + + + + + Specifies the Stream Control Transmission Protocol. + + + + + Specifies the Siemens Sinec H1 protocol. + + + + + Specifies the Sequenced Packet Exchange protocol. + + + + + Specifies the Datagram Congestion Control Protocol. + + + + + + + Layer7ProtocolEnum is a non-exhaustive enumeration of Layer 7 (application) layer protocols. + + + + + Specifies the Hypertext Transfer Protocol. + + + + + Specifies the Hypertext Transfer Protocol Secure. + + + + + Specifies the File Transfer Protocol. + + + + + Specifies the Simple Mail Transfer Protocol. + + + + + Specifies the Internet Relay Chat protocol. + + + + + Specifies the Identification Protocol, IDENT. + + + + + Specifies the Domain Name System protocol. + + + + + Specifies the Telnet protocol. + + + + + Specifies the Post Office Protocol, version 3. + + + + + Specifies the Internet Message Access Protocol. + + + + + Specifies the Secure Shell protocol. + + + + + Specifies the Microsoft Server Message Block protocol. + + + + + Specifies the Advance Direct Connect protocol. + + + + + Specifies the Apple Filing Protocol. + + + + + Specifies the Building Automation and Control Network protocol. + + + + + Specifies the BitTorrent protocol. + + + + + Specifies the Bootstrap Protocol. + + + + + Specifies the Diameter protocol. + + + + + Specifies the Digital Imaging and Communications in Medicine protocol. + + + + + Specifies the Dictionary protocol. + + + + + Specifies the Digital Storage Media Command and Control protocol. + + + + + Specifies the Distributed Social Networking Protocol. + + + + + Specifies the Dynamic Host Configuration Protocol. + + + + + Specifies the EDonkey2000 protocol. + + + + + Specifies the Finger protocol. + + + + + Specifies the Gnutella protocol. + + + + + Specifies the Gopher protocol. + + + + + Specifies the ISDN User Part protocol. + + + + + Specifies the Lightweight Directory Access Protocol. + + + + + Specifies the Multipurpose Internet Mail Extensions protocol. + + + + + Specifies the Microsoft Notification Protocol. + + + + + Specifies the Mobile Application Part protocol. + + + + + Specifies the Network Basic Input/Output System protocol. + + + + + Specifies the Network News Transfer Protocol. + + + + + Specifies the Network Time Protocol. + + + + + Specifies the National Transportation Communications for Intelligent Transportation System Protocol. + + + + + Specifies the Remote Authentication Dial In User Service protocol. + + + + + Specifies the Remote Desktop Protocol. + + + + + Specifies the rlogin protocol. + + + + + Specifies the rsync otocol. + + + + + Specifies the Real-time Transport Protocol. + + + + + Specifies the Real-time Transport Streaming Protocol. + + + + + Specifies the Siebel Internet Session Network API protocol. + + + + + Specifies the Session Initiation Protocol. + + + + + Specifies the Simple Network Management Protocol. + + + + + Specifies the Session Traversal Utilities for NAT protocol. + + + + + Specifies the Telephonse User Part protocol. + + + + + Specifies the Transaction Capabilities Application Part protocol. + + + + + Specifies the Trivial File Transfer Protocol. + + + + + Specifies the Web Distributed Authoring and Versioning protocol. + + + + + Specifies the Extensible Messaging and Presence Protocol. + + + + + diff --git a/stix_validator/schema/cybox/objects/Network_Flow_Object.xsd b/stix_validator/schema/cybox/objects/Network_Flow_Object.xsd new file mode 100755 index 0000000..c1b69b5 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Network_Flow_Object.xsd @@ -0,0 +1,1559 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Network_Flow_Object + 2.0 + 03/27/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + + The Network_Flow_Object object provides a summary of network traffic, expressed as flows of multiple packets instead of individual packets, without the packet payload data (i.e. the actual data that was uploaded/downloaded to and from the Dest IP to Source IP as included in ppaacket monitoring tools, such as Wireshark). + + + + + Defines the fields necessary to summarize network traffic, expressed as flows of multiple packets. Does not include the packet payload data (i.e. the actual data that was uploaded/downloaded to and from the Dest IP to Source IP as included in packet monitoring tools, such as Wireshark). + + + + + + + Represents elements common to all flow records formats - either expressed as a 5-tuple or an extended 7-tuple (actually an 8-tuple because for organizational reasons, we include the egress interface index). Because these fields are defined here, they are excluded from the fields associated directly with each different flow record format type. + + + + + + Represents flow-record formats that capture data in one direction only (e.g., Netflow v9). + + + + + Represents flow-record formats that capture data in both directions (e.g., YAF). + + + + + + + + + + Network layer information (relative to the OSI network model) which is typically captured in all types of network flow records. + + + + + Represents the source IP socket addres, consisting of an IP address and port number, for the network flow expressed. Note that not all flow protocols support IPv6 addresses. + + + + + Represents the destination IP socket addres, consisting of an IP address and port number, for the network flow expressed. Note that not all flow protocols support IPv6 addresses. + + + + + The IP Protocol of the network flow. This is usually TCP, UDP, or SCTP, but can include others as represented in NetFlow as an integer from 0 to 255. Please refer to http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml for reference. + + + + + + + The NetworkFlowLabelType contains elements that are common to all flow record formats. It builds off of network layer information (a 5-tuple that commonly defines a flow) and includes ingress and egress interface indexes and IP protocol information (not present if all flow record formats). Egress information is usually not thought of as part of the extended 7-tuple, but we include it for organizational purposes. Because these fields are defined here, they are excluded from the fields associated directly with each different flow record format type. + + + + + + + Represents the index (in SNMP, by default) of the network interface card where the flows entered the router. + + + + + Represents the index (in SNMP, by default) of the network interface card where the flows leave the router. + + + + + Type of service field from the IP header. Specifies the IP Type of Service (ToS). See RFC 1349 for more information. + + + + + + + + + Netflow record formats that capture traffic in one direction. + + + + + Represents an Internet Protocol Flow Information eXport (IPFIX) protocol. IPFIX is based on NetFlow v9. Has several extensions such as Enterprise-defined fields types and variable length fields. See RFC 5101 for more information. + + + + + Represents the Netflow V9 flow record format. See RFC 3954 (Netflow v9) for more information. + + + + + Represents the NetFlow v5 flow record format, which is commonly used to represent network flow data. + + + + + Represents a network flow record in the System for Internet-Level Knowledge (SiLK) format, developed by CERT at Carnegie Mellon University (CMU)'s Software Engineering Institute (SEI) as part of the NetSA security suite. See http://tools.netsa.cert.org/silk/analysis-handbook.pdf for more information. + + + + + + + Network record formats that capture traffic in both directions. Later, we plan to add Argus as a network flow format type. Argus supports bidirectional flows, and as such, is usually used as an alternative to NetFlow v5 analysis via SiLK (http://www.qosient.com/argus/). + + + + + Represents flow records generated via YAF (Yet Another Flowmeter), a bidirectional network flow meter. See http://www.usenix.org/event/lisa10/tech/full_papers/Inacio.pdf or http://tools.netsa.cert.org/yaf/index.html for more information. + + + + + + + The IPFIX protocol provides IP flow information. http://tools.ietf.org/html/rfc5101 + + + + + The Message Header is the first part of an IPFIX Message, which provides basic information about the message, such as the IPFIX version, length of the message, message sequence number, etc. http://tools.ietf.org/html/rfc5101 + + + + + + Set is a generic term for a collection of records that have a similar structure. In an IPFIX Message, one or more Sets follow the Message Header. http://tools.ietf.org/html/rfc5101 + + + + + + + + This type represents the message header for the IPFIX format. For more information about each of the fields, please refer to RFC 5101 (http://tools.ietf.org/html/rfc5101) under the heading, "Message Header Field Descriptions." Note that common elements are included in the Network_Flow_Label. + + + + + Indicates the version number of Flow Record format exported in this message. The value of this field is 0x000a for the current version, incrementing by one the version used in the NetFlow services export version 9 [see RFC3954]. + + + + + Indicates the total byte length of the IPFIX Message, measured in octets, including Message Header and Set(s). + + + + + Indicates the time, in seconds, since 0000 UTC Jan 1, 1970, at which the IPFIX message header leaves the Exporter. + + + + + Indicates the incremental sequence counter modulo 2^32 of all IPFIX Data Records sent on this PR-SCTP stream from the current Observation Domain by the Exporting Process. This value SHOULD be used by the Collecting Process to identify whether any IPFIX Data Records have been missed. Template and Options Template Records do not increase the Sequence Number. + + + + + Indicates a 32-bit identifier of the Observation Domain that is locally unique to the Exporting Process. See RFC 5101 under Observation Domain ID for more information. + + + + + + + Represents the possible sets of records that can be represented in an IPFIX message. See RFC 5101 and look for the terms "Template Set", "Options Template Set", and "Data Set", for more information. + + + + + Indicates a collection of one or more Template Records that have been grouped together in an IPFIX message. + + + + + Indicates a collection of one or more Options Template Records that have been grouped together in an IPFIX message. + + + + + Indicates one or more Data Records, of the same type, that have been grouped together in an IPFIX message. Each Data Record is previously defined by a Template Record or an Options Template Record. + + + + + + + Specifies the regions of a Template Set, of which there are three: the Set Header, the collection of Template Records, and the optional padding at the end of the Template Set. See RFC 5101 under Set Format, which is section 3.3.1, for more information. + + + + + Indicates the Set Header region, which is 32-bit region containing the 16-bit fields Set ID and Length. + + + + + Indicates the region of Template Records. These are the same fields referenced in the IPFIXTemplateRecordType. + + + + + Indicates the optional Padding at the end of a Template Set. As mentioned in RFC 5101, the Exporting Process MAY insert some padding octets, so that the subsequent Set starts at an aligned boundary. For security reasons, the padding octet(s) MUST be composed of zero (0) valued octets, and the padding length MUST be shorter than any allowable record in this Set. For more information see RFC 5101 under Padding. + + + + + + + Specifies the regions of an Options Template Set, of which there are three: the Set Header, the collection of Options Template Records, and the optional padding at the end of the Options Template Set. See RFC 5101 under Set Format, which is section 3.3.1, for more information. + + + + + Indicates the Set Header region, which is 32-bit region containing the 16-bit fields Set ID and Length, in that order. These are the same fields referenced in the IPFIXSetHeaderType. + + + + + Indicates the region of Options Template Records. These are the same fields referenced in the IPFIXOptionsTemplateRecordType. + + + + + Indicates the optional Padding at the end of an Options Template Set. As mentioned in RFC 5101, the Exporting Process MAY insert some padding octets, so that the subsequent Set starts at an aligned boundary. For security reasons, the padding octet(s) MUST be composed of zero (0) valued octets, and the padding length MUST be shorter than any allowable record in this Set. For more information see RFC 5101 under Padding. + + + + + + + Specifies the regions of a Data Set, of which there are three: the Set Header, the collection of Data Records, and the optional padding at the end of the Data Set. See RFC 5101 under Set Format, which is section 3.3.1, for more information. + + + + + Indicates the Set Header region, which is 32-bit region containing the 16-bit fields Set ID and Length, appended in that order. These are the same fields referenced in the IPFIXSetHeaderType. + + + + + Indicates the region of Data Records, which consist of a series of field values without a header, according to RFC 5101, section 3.4.3. + + + + + Indicates the optional Padding at the end of a Data Set. As mentioned in RFC 5101, the Exporting Process MAY insert some padding octets, so that the subsequent Set starts at an aligned boundary. For security reasons, the padding octet(s) MUST be composed of zero (0) valued octets, and the padding length MUST be shorter than any allowable record in this Set. For more information see RFC 5101 under Padding. + + + + + + + Defines the elements of the IPFIX set header. + + + + + Indicates a 16-bit value that identifies the set. The values of 0 and 1 are not used for historical reasons according to RFC 3954. Otherwise, a value of 2 is reserved for the Template Set and 3 is reserved for the Option Template Set. All other values from 4 to 255 are reserved for future use. + + + + + Total length of the set, in octets, including the set header, all records, and the optional padding. Because an individual Set MAY contain multiple records, the Length value MUST be used to determine the position of the next Set. http://tools.ietf.org/html/rfc5101 + + + + + + + Specifies the regions of a Template Record, of which there are two: the Template Record Header, and the Field Specifiers. See RFC 5101 under Template Record Format, section 3.4.1, for more information. + + + + + Indicates the Template Record Header region, which is a 32-bit region containing the 16-bit fields Template ID (> 255) and Field Count, appended in that order. These are the same fields referenced in the IPFIXTemplateRecordHeaderType. + + + + + Indicates the region of Field Specifiers. These are the same fields referenced in the IPFIXTemplateRecordFieldSpecifiersType. + + + + + + + Specifies the fields in a Template Record Header, Template_ID and Field_Count, as explained in RFC 5101, section 3.4.1. + + + + + Specifies a unique Template ID which is numbered 256-65535 since IDs 0-255 are reserved for Template Sets, Options Template Sets, and other reserved Sets yet to be created. + + + + + Specifies the number of fields in this Template Record. + + + + + + + Specifies the fields in a Template Record Field Specifier, as explained in RFC 5101, section 3.2. + + + + + Specifies the Enterprise bit, either 0 or 1. If this bit is zero, the Information Element Identifier identifies an IETF-specified Information Element, and the four-octet Enterprise Number field SHOULD NOT be present. If this bit is one, the Information Element identifier identifies an enterprise-specific Information Element, and the Enterprise Number filed SHOULD be present. NOTE: While it is legal to use "true" and "false" here, this value SHOULD be set to 0 or 1 for consistency with RFC 5101. + + + + + Specifies the 15-bit (NOT 16-bit) Information Element ID referring to the type of Information Element, as shown in RFC 5102. + + + + + Specifies the 16-bit Field Length, in octets, of the corresponding encoded Information Element as defined in RFC 5102. The field length may be smaller than the definition in RFC 5102 if the reduced size encoding is used (see Section 6.2 of RFC 5101). The value 65535 is reserved for variable length Information Elements. + + + + + Specifies the 32-bit IANA Enterprise Number of the authority defining the Information Element identifier in this Template Record. Information Element Identifiers 1.2 and 2.1 are defined by the IETF (Enterprise bit = 0) and, therefore, do not need an Enterprise Number to identify them. + + + + + + + Specifies the regions of an Options Template Record, of which there are two: the Options Template Record Header, and the Field Specifiers. See RFC 5101 under Options Template Record Format, section 3.4.2.2, for more information. + + + + + Indicates the Options Template Record Header region, which is a 48-bit region containing the 16-bit fields Template ID, Field Count, and Scope Field Count, appended in that order. + + + + + Indicates the region of Field Specifiers. These are the same fields referenced in the IPFIXOptionsTemplateRecordFieldSpecifiersType. + + + + + + + Defines the ehader of an options template record. + + + + + Specifies a unique Template ID which is numbered 256-65535 since IDs 0-255 are reserved for Template Sets, Options Template Sets, and other reserved Sets yet to be created. + + + + + Specifies the number of fields in this Options Template Record, INCLUDING the Scope Fields. + + + + + Specifies the number of scope fields in this Options Template Record, which is NONZERO. The Scope Fields are normal Fields except that they are interpreted as scope at the Collector. + + + + + + + Specifies the fields in an Options Template Record Field Specifier, as explained in RFC 5101, sections 3.2 and 3.4.2.2. It consists of two sequences: Scope Fields and Option Fields, appended together. + + + + + + Specifies the Scope Enterprise bit, either 0 or 1. If this bit is zero, the Information Element Identifier identifies an IETF-specified Information Element, and the four-octet Enterprise Number field SHOULD NOT be present. If this bit is one, the Information Element identifier identifies an enterprise-specific Information Element, and the Enterprise Number filed SHOULD be present. NOTE: While it is legal to use "true" and "false" here, this value SHOULD be set to 0 or 1 for consistency with RFC 5101. + + + + + Specifies the 15-bit (NOT 16-bit) Scope Information Element ID referring to the type of Information Element, as shown in RFC 5102. + + + + + Specifies the 16-bit Scope Field Length, in octets, of the corresponding encoded Information Element as defined in RFC 5102. The field length may be smaller than the definition in RFC 5102 if the reduced size encoding is used (see Section 6.2 of RFC 5101). The value 65535 is reserved for variable length Information Elements. + + + + + Specifies the 32-bit IANA Scope Enterprise Number of the authority defining the Information Element identifier in this Template Record. Information Element Identifiers 1.2 and 2.1 are defined by the IETF (Enterprise bit = 0) and, therefore, do not need an Enterprise Number to identify them. + + + + + + + Specifies the Option Enterprise bit, either 0 or 1. If this bit is zero, the Information Element Identifier identifies an IETF-specified Information Element, and the four-octet Enterprise Number field SHOULD NOT be present. If this bit is one, the Information Element identifier identifies an enterprise-specific Information Element, and the Enterprise Number filed SHOULD be present. NOTE: While it is legal to use "true" and "false" here, this value SHOULD be set to 0 or 1 for consistency with RFC 5101. + + + + + Specifies the 15-bit (NOT 16-bit) Option Information Element ID referring to the type of Information Element, as shown in RFC 5102. + + + + + Specifies the 16-bit Option Field Length, in octets, of the corresponding encoded Information Element as defined in RFC 5102. The field length may be smaller than the definition in RFC 5102 if the reduced size encoding is used (see Section 6.2 of RFC 5101). The value 65535 is reserved for variable length Information Elements. + + + + + Specifies the 32-bit IANA Option Enterprise Number of the authority defining the Information Element identifier in this Template Record. Information Element Identifiers 1.2 and 2.1 are defined by the IETF (Enterprise bit = 0) and, therefore, do not need an Enterprise Number to identify them. + + + + + + + + Data records are sent in data sets. A data record consists of only one more more Field values. + + + + + Indicates the individual Field Value, which need not be 16-bit. The Template ID to which the Field Values belong to is encoded in the Data Set Header field "Set ID", i.e. "Set ID" = "Template ID". + + + + + + + Netflow v9 was developed by Cisco and provides acess to IP flow information. http://www.ietf.org/rfc/rfc3954.txt + + + + + Specifies the Packet Header, which is the first part of an Export Packet. The Packet Header provides basic information about the packet such as the NetFlow version, number of records contained within the packet, and sequence numbering. See RFC 3954 for more information. + + + + + + Specifies a FlowSet, which is a collection of Flow Records that have similar structure. In an Export Packet, one or more FlowSets follow the Packet Header. There are three differnet types of FlowSets, as defined in RFC 3954: a Template FlowSet, Options Template FlowSet and Data FlowSet. + + + + + + + + Header fields defined for Netflow v9. Note that common elements are included in the Network_Flow_Label. http://www.ietf.org/rfc/rfc3954.txt + + + + + Specifies the version of flow record format exported in this packet. The value of this field is 9 for the Netflow v9. + + + + + Specifies the total number of records in the Export Packet, which is the sum of Options FlowSet records, Template FlowSet records, and Data FlowSet records. http://www.ietf.org/rfc/rfc3954.txt + + + + + Specifies the time in milliseconds since this device was first booted. + + + + + Specifies the time in seconds since 0000 UTC 1970 at which the Export Packet leaves the Exporter. + + + + + Incremental sequence counter of all Export Packets sent from the current Observation Domain by the Exporter. This value MUST be cumulative, and SHOULD be used by the Collector toidentify whether any Export Packets have been missed. http://www.ietf.org/rfc/rfc3954.txt + + + + + Specifies a 32-bit value that identifies the Exporter Observation Domain. NetFlow Collectors SHOULD use the combination of the source IP address and the Source ID field to separate different export streams originating from the same Exporter. + + + + + + + In an Export Packet, one or more FlowSets follow the Packet Header. There are three differnet types of FlowSets, as defined in RFC 3954: a Template FlowSet, Options Template FlowSet and Data FlowSet. + + + + + One of the essential elements in the NetFlow format is the Template FlowSet. Templates greatly enhance the flexibility of the Flow Record format because they allow the NetFlow Collector to process Flow Records without necessarily knowing the interpretation of all the data in the Flow Record. http://www.ietf.org/rfc/rfc3954.txt + + + + + Specifies an Options Template FlowSet, which is one or more Options Template Records that have been grouped together in an Export Packet. + + + + + Specifies a Data FlowSet, which is one or more records, of the same type, that are grouped together in an Export Packet. Each record is either a Flow Data Record or an Options Data Record previously defined by a Template Record or an Options Template Record. + + + + + + + Provides the format of the Template FlowSet. + + + + + Specifies the FlowSet ID, which is fixed to 0 for the Template FlowSet. + + + + + Length is the sum of the lengths of the FlowSet ID, the Length itself, and all Template Records within this FlowSet. + + + + + Specifies the Template Record region, which includes the template ID, field count, field type, and field length. + + + + + + + Specifies the Template Record region, which includes the template ID, field count, field type, and field length. + + + + + Specifies a unique Template ID for the Template Record. IDs in the range 0-255 are reserved for Template FlowSets, Options FlowSets, and other reserved Sets yet to be created. http://www.ietf.org/rfc/rfc3954.txt + + + + + Specifies the number of fields in this Template Record. + + + + + Number of fields corresponds to Count field. + + + + Specifies a numeric value that represents the type of the field. Refer to the "Field Type Definitions" section in RFC 3954 for descriptions of these types. + + + + + Specifies the length of the corresponding field type, in bytes. + + + + + + + + NetflowV9FieldType specifies possible fields types for Netflow v9, via a union of the NetflowV9FieldTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + This enumeration describe the field types in NetFlow Version 9. Only the first 20 have been enumerated so far. Please see Section 8 in http://www.ietf.org/rfc/rfc3954.txt for the complete list (79 in total). + + + + + The IN_BYTES(1) field represents the incoming counter with length N x 8 bits for number of bytes associated with an IP Flow. + + + + + The IN_PKTS(2) field represents the incoming counter with length N x 8 bits for the number of packets associated with an IP Flow. + + + + + The FLOWS(3) field represents the number of flows that were aggregated; default for N is 4. + + + + + The PROTOCOL(4) field represents the IP protocol byte. + + + + + The TOS(5) field represents the Type of Service byte setting when entering incoming interface. + + + + + The TCP_FLAGS(6) field is cumulative of all the TCP flags seen for this flow. + + + + + The L4_SRC_PORT(7) field represents the TCP/UDP source port number i.e.: FTP, Telnet, or equivalent. + + + + + The IPV4_SRC_ADDR(8) field represents the IPv4 source address. + + + + + The SRC_MASK(9) field represents the number of contiguous bits in the source address subnet mask i.e.: the submask in slash notation. + + + + + The INPUT_SNMP(10) field represents the number of contiguous bits in the source address subnet mask i.e.: the submask in slash notation. + + + + + The LP_DST_PORT(11) field represents the TCP/UDP destination port number i.e.: FTP, Telnet, or equivalent. + + + + + The IPV4_DST_ADDR(12) field represents the IPv4 destination address. + + + + + The DST_MASK(13) field represents the number of contiguous bits in the destination address subnet mask i.e.: the submask in slash notation. + + + + + The OUTPUT_SNMP(14) field represents the output interface index; default for N is 2 but higher values could be used. + + + + + The IPV4_NEXT_HOP(15) field represents the IPv4 address of next-hop router. + + + + + The SRC_AS(16) field represents the source BGP autonomous system number where N could be 2 or 4. + + + + + The DST_AS(17) field represents the destination BGP autonomous system number where N could be 2 or 4. + + + + + The BGP_IPV4_NEXT_HOP(18) field represents the next-hop router's IP in the BGP domain. + + + + + The MUL_DST_PKTS(19) field represents the IP multicast outgoing packet counter with length N x 8 bits for packets associated with the IP Flow. + + + + + The MUL_DST_BYTES(20) field represents the IP multicast outgoing byte counter with length N x 8 bits for bytes associated with the IP Flow. + + + + + + + Specifies an Options Template FlowSet, which is one or more Options Template Records that have been grouped together in an Export Packet. + + + + + Specifies the FlowSet ID, which is fixed to 1 for the Options Template FlowSet. + + + + + Specifies the total length of this FlowSet, in octets, including the set header, all records, and the optional padding. + + + + + Specifies the Options Template Record region, which includes the Option Scope Length, Option Length, and fields specifying the Scope field type and Scope field length. + + + + + Specifies the number of padding bytes to be inserted so that the subsequent FlowSet starts at a 4-byte aligned boundary. It is important to note that the Length field includes the padding bytes. Padding SHOULD be using zeros. + + + + + + + Specifies the Options Template Record region, which includes the Option Scope Length, Option Length, and fields specifying the Scope field type and Scope field length. + + + + + Specifies the template ID of this Options Template, which must be greater than 255. + + + + + Specifies the length of bytes of any Scope field definition contained in the Options Template Record. + + + + + Specifies the length of bytes of any options field definitions contained in this Options Template Record. + + + + + + Specifies the relevent portion of the Exporter/NetFlow process to which the Options Template Record refers. Currently defined values include 1 for System, 2 for Interface, 3 for Line Card, 4 for Cache, and 5 for Template. More information can be found in RFC 3954. + + + + + Specifies the length (in bytes) of the Scope field as it would appear in an Options Data Record. + + + + + + + Specifies the type of field that would appear in the Options Template Record. More information can be found in RFC 3954. + + + + + Specifies the length (in bytes) of the Option field. + + + + + + + + NetflowV9ScopeFieldType specifies scope field types for Netflow v9, via a union of the NetflowV9ScopeFieldTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + These describe the scope field types, found in the relevant portion of the NetFlow process to which the options record refers. http://www.ietf.org/rfc/rfc3954.txt + + + + + Indicates the System scope field type. + + + + + Indicates the Interface scope field type. + + + + + Indicates the Line Card scope field type. + + + + + Indicates the NetFlow Cache scope field type. + + + + + Describes the Template scope field type. + + + + + + + Specifies a Data FlowSet, which is one or more records, of the same type, that are grouped together in an Export Packet. Each record is either a Flow Data Record or an Options Data Record previously defined by a Template Record or an Options Template Record. http://www.ietf.org/rfc/rfc3954.txt + + + + + Specifies the FlowSet ID, which corresponds to the Template ID from a Template Flow Set or an Options Template Flow Set. + + + + + Specifies the length of this FlowSet. + + + + + The remainder of the Data FlowSet is a collection of Flow Data Record(s), each containing a set of field values. The Type and Length of the fields have been previously defined in the Template Record referenced by the FlowSet ID or Template ID. Specifies either a template flow set or an options template flow set. http://www.ietf.org/rfc/rfc3954.txt + + + + + Specifies the padding bytes used so that the subsequent FlowSet starts at a 4-byte aligned boundary. It is important to note that the Length field includes the padding bytes. Padding SHOULD be using zeros. + + + + + + + A Data FlowSet is one or more records, of the same type, that are grouped together in an Export Packet. Each record is either a Flow Data Record or an Options Data Record previously defined by a Template Record or an Options Template Record. http://www.ietf.org/rfc/rfc3954.txt + + + + + + + + + Specifies a Flow Data Record, which corresponds to a FieldType defined in the Template Record. Each one will have multiple values associated with it. + + + + + + + Specifies an Options Data Record, which Corresponds to a previously defined Options Template Record. + + + + + + + + A Flow Data Record is a data record that contains values of the Flow parameters corresponding to a Template Record. + + + + + For each flow record, field values are listed. + + + + + + + Field values are associated with each record in the collection of a flow data record. + + + + + Set of fields values for a given Flow Data Record. + + + + + + + The data record that contains values and scope information of the Flow measurement parameters, corresponding to an Options Template Record. + + + + + Corresponds to a previously defined Options Template Record. + + + + + + For each option data record, field values are listed. + + + + + + + + Field values are associatedwith each option in the collection of an option data record. + + + + + Set of field values for a given Options Data Record. + + + + + + + Defines the contents of a Netflow v5 packet. As of 2012, Netflow v5 is still the most commonly used network flow format. Netflow v5 was developed by Cisco. http://netflow.caligare.com/netflow_v5.htm + + + + + Elements of a netflow v5 header. + + + + + + See Network_Flow_Label for other common fields. Padding of 0-bytes is not captured. REF: http://netflow.caligare.com/netflow_v5.htm REF: http://tools.netsa.cert.org/silk/faq.html#ipfix-fields + + + + + + + + Defines elements of a netflow v5 header. http://netflow.caligare.com/netflow_v5.htm + + + + + Specifies the NetFlow export format version number, which defaults to 5 in this case. + + + + + Specifies the number of flows exported in the packet (1-30). + + + + + Specifies the current time in milliseconds since the export device booted. + + + + + Specifies the current time in milliseconds since 0000 UTC 1970. + + + + + Specifies the residual in nanoseconds since 0000 UTC 1970. + + + + + Specifies the sequence counter of total flows seen. + + + + + Specifies the type of flow-switching engine. + + + + + Specifies the slot number of the flow-switching engine. + + + + + Specifies the sampling interval field, which consists of the first two bits holding the sampling mode, with the remaining 14 bits holding the value of the sampling interval. + + + + + + + Defines elements of a Netflow v5 flow record. Recall that the seven elements that define the flow itself (e.g., source IP address) are provided in NetworkFlowLabelType. https://bto.bluecoat.com/packetguide/8.6/info/netflow5-records.htm + + + + + Represents the IP address of the next hop router. + + + + + Represents the number of packets in the flow. + + + + + Represents the total number of bytes in the flow. + + + + + Represents the SysUpTime at start of flow: the total time in milliseconds starting from when the first packet in the flow was seen. + + + + + Represents the SysUpTime at end of flow: when the last packet in the flow was seen. + + + + + One byte of padding. + + + + + Specifies the union of all TCP flags observed over the life of the flow. + + + + + Specifies the source autonomous system number, either origin or peer. + + + + + Specifies the destination autonomous system number, either origin or peer. + + + + + Specifies the source address prefix mask bits. + + + + + Specifies the destination address prefix mask bits. + + + + + Unused (zero) bytes, which is used for purposes of padding. + + + + + + + System for Internet-Level Knowledge (CMU/SEI). The fields are taken from a list shown in http://tools.netsa.cert.org/silk/rwcut.html. Fields common to all network flows are defined in NetworkFlowLabelType (e.g., source IP, SNMP ingress, etc.). For additional references, see http://tools.netsa.cert.org/silk/analysis-handbook.pdf, http://tools.netsa.cert.org/silk/faq.html#ipfix-fields. + + + + + Represents the number of packets in the flow. + + + + + Represents the number of Layer 3 bytes in the packets of the flow. + + + + + Specifies the union of all TCP flags observed over the life of the flow. + + + + + Represents the SysUpTime at start of flow, i.e. the total time in milliseconds starting from when the router booted. There is another element "Start_Time+msec" which is the starting time of flow including milliseconds, but milliseconds are the resolution of Start_Time unless the -legacy-timestamps switch is specified, so "Start_Time+msec" is not defined separately. + + + + + Specifies the duration of the flow. There is another element "Duration+msec" which is the starting time of flow including milliseconds, but milliseconds are the resolution of Duration unless the -legacy-timestamps switch is specified, so "Duration+msec" is not defined separately. + + + + + Represents the SysUpTime at end of flow. There is another element "End_Time+msec" which is the starting time of flow including milliseconds, but milliseconds are the resolution of End_Time unless the -legacy-timestamps switch is specified, so "End_Time+msec" is not defined separately. + + + + + Defines the fields associated with the sensor at the collection point. + + + + + ICMP type for ICMP flows. Empty for non-ICMP flows. + + + + + ICMP code for ICMP flows. Empty for non-ICMP flows. + + + + + Router next hop IP. + + + + + TCP flags on first packet in the flow. + + + + + bit-wise OR of TCP flags over all packets except the first in the flow + + + + + Flow attributes set by the flow generator. + + + + + Based on an examination of payload contents, this value = the port number traditionally used for that type of traffic (21 for FTP traffic even if actually routed over port 80). Documentation (http://tools.netsa.cert.org/silk/rwcut.html) says this is a "guess as to the content of the flow". + + + + + The type of the source IP in terms of whether the address is routable, external, etc. + + + + + The type of the destination IP in terms of whether the address is routable, external, etc. + + + + + A two-letter country code denoting the country of location of the source IP address. + + + + + A two-letter country code denoting the country of location of the destination IP address. + + + + + User defined string for integrating external information into SiLK records. See documentation on SiLK pmap filter for details (defined in the prefix map associated with MAPNAME). + + + + + User defined string for integrating external information into SiLK records. See documentation on SiLK pmap filter for details (defined in the prefix map associated with MAPNAME). + + + + + + + SiLKFlowAttributesType specifies SiLK flow attributes, via a union of the SiLKFlowAttributesTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The SiLKFlowAttributesTypeEnum specifies the flow attributes set by the flow generator. This is field 28 of the rwstats options. See http://tools.netsa.cert.org/silk/rwstats.html for more information. + + + + + Indicates that the flow generator saw additional packets in this flow following a packet with a FIN flag (excluding ACK packets). + + + + + Indicates that the flow generator prematurely created a record for a long-running connection due to a timeout. (When the flow generator yaf(1) is run with the --silk switch, it will prematurely create a flow and mark it with T if the byte count of the flow cannot be stored in a 32-bit value.) + + + + + Indicates that the flow generator created this flow as a continuation of long-running connection, where the previous flow for this connection met a timeout (or a byte threshold in the case of yaf). + + + + + + + SiLKAddressType specifies SiLK address types, via a union of the SiLKAddressTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + Environment variable allows user to specify the address type mapping file. A partial, typical list is currently given--see http://tools.netsa.cert.org/silk/addrtype.html for more information. + + + + + Denotes a (non-routable) IP address. + + + + + Denotes an IP address internal to the monitored network. + + + + + Denotes an IP address external to the monitored network. + + + + + + + SiLKCountryCodeType specifies country codes used by SiLK, via a union of the SiLKCountryCodeTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + Environment variable allows user to specify a country code mapping file. No enumerations are currently defined. + + + + + + Defines elements associated with a SiLK sensor. + + + + + Name or ID of sensor at the collection point. + + + + + By default, only one "all" class. Others can be configured. + + + + + Specifies the direction of traffic, which is enumerated by SiLKDirectionType. + + + + + + + SiLKType specifies direction of SiLK traffic, via a union of the SiLKDirectionTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + Enumerates direction of traffic. Not all are currently enumerated. + + + + + Denotes inbound traffic relative to a sensor. + + + + + Denotes inbound web traffic relative to a sensor. SiLK categorizes a flow as web if the protocol is TCP and either the source port or destination port is one of 80, 443, or 8080. + + + + + Denotes null inbound traffic relative to a sensor. + + + + + Denotes outbound traffic relative to a sensor. + + + + + Denotes outbound web traffic relative to a sensor. SiLK categorizes a flow as web if the protocol is TCP and either the source port or destination port is one of 80, 443, or 8080. + + + + + Denotes null outbound traffic relative to a sensor. + + + + + + + SiLKSensorClassType specifies the sensor class, via a union of the SiLKSensorClassTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + Enumerates SiLK sensor classes. Currently just one class (all) is defined. + + + + + Defines sensor class "all". + + + + + + + YAF (Yet Another Flowmeter) is bidirectional network flow meter. It processes packet data from pcap(3) dumpfiles as generated by tcpdump(1) or via live capture from an interface using pcap(3) into bidirectional flows, then exports those flows to IPFIX. (REF: http://www.usenix.org/event/lisa10/tech/full_papers/Inacio.pdf) + + + + + The elements in a YAF record have been separated based on flow direction. These elements are defined for the general forward flow. + + + + + Some elements in a YAF record correspond to the reverse flow. These elements are given here. + + + + + + + These elements of a YAF record correspond to the flow generally or to the forward portion of the flow. Elements common to all network flow objects are defined in the NetworkFlowLabelType (src ip address, ingress/egress interface). + + + + + Flow start time in milliseconds since 1970-01-01 00:00:00 UTC + + + + + Flow end time in milliseconds since 1970-01-01 00:00:00 UTC + + + + + Number of octets in packets in forward direction of flow. May be encoded in 4 octets using IPFIX reduced-length encoding. + + + + + Number of packets in forward direction of flow. + + + + + The reason for Flow termination. It may contain SiLK-specific tags. The range of values may include the following: 0x01: idle timeout (the Flow was terminated because it was considered to be idle). 0x02: active timeout (the Flow was terminated for reporting purposes while it was still active, for example, after the maximum lifetime of unreported Flows was reached). 0x03: end of Flow detected (the Flow was terminated because the Metering Process detected signals indicating the end of the Flow, for example, the TCP FIN flag.) 0x04: forced end (the Flow was terminated because of some external event, for example, a shutdown of the Metering Process initiated by a network management application.) 0x05: lack of resources (the Flow was terminated because of lack of resources available to the Metering Process and/or the Exporting Process.) See http://www.iana.org/assignments/ipfix/ipfix.xml for more information. + + + + + The SiLK_App_Label is the port number that is traditionally used for that type of traffic (see the /etc/services file on most UNIX systems). For example, traffic that the flow generator recognizes as FTP will have a value of 21, even if that traffic is being routed through the standard HTTP/web port (80). + + + + + Shannon Entropy calculation of the forward payload data. The calculation generates a real number value between 0.0 and 8.0. That number is then converted into an 8-bit integer value between 0 and 255. Roughly, numbers above 230 are generally compressed (or encrypted) and numbers centered around approximately 140 are English text. Lower numbers carry even less information content. + + + + + Machine-learning app label + + + + + Contains TCP-related information of the network flow. + + + + + The MAC adress. + + + + + OS name and version. + + + + + First forward packet IP payload. + + + + + Second forward packet IP payload. + + + + + Initial n bytes of forward direction of applications payload. + + + + + + + These elements correspond to the reverse flow captured by in YAF record. + + + + + Number of octets in packets in reverse direction of flow. May be encoded in 4 octets using IPFIX reduced-length encoding. + + + + + Number of packets in reverse direction of flow. + + + + + Shannon Entropy calculation of the reverse payload data. The calculation generates a real number value between 0.0 and 8.0. That number is then converted into an 8-bit integer value between 0 and 255. Roughly, numbers above 230 are generally compressed (or encrypted) and numbers centered around approximately 140 are English text. Lower numbers carry even less information content. + + + + + RTT of initial handshake. + + + + + The associated elements relate to the reverse packets of the flow. + + + + + Reverse MAC address. + + + + + OS name and version of the reverse flow. + + + + + First reverse packet IP payload. + + + + + Initial n bytes of reverse direction of flow payload + + + + + + + Contains TCP-related information of the network flow. + + + + + TCP sequence number. + + + + + TCP flags of the first packet. + + + + + The union of the TCP flags of the 2...nth packet. + + + + + diff --git a/stix_validator/schema/cybox/objects/Network_Packet_Object.xsd b/stix_validator/schema/cybox/objects/Network_Packet_Object.xsd new file mode 100755 index 0000000..deb93f7 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Network_Packet_Object.xsd @@ -0,0 +1,2948 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Network_Packet_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + The Network_Packet object provides the definition of a network packet based on the TCP/IP model/Internet protocol suite. In the TCP/IP stack, "packet" is generally defined as IP header plus payload, but we also include the LinkLayer from the OSI model, which defines the physical network interfaces and routing protocols. The application layer has not yet been defined. + + + + + The NetworkPacketObjectType's definition of a network packet is based on the TCP/IP model/Internet protocol suite. In the TCP/IP stack, "packet" is generally defined as IP header plus payload, but we also include the LinkLayer from the OSI model, which defines the physical network interfaces and routing protocols. Protocol fields are provided but requirements are not enforced/captured; all fields are optional. + + + + + + + The Link Layer is the lowest layer of the TCP/IP network stack and is comprised of physical and logical protocols that operate between adjacent nodes of a network segment or a WAN connection. + + + + + Internet layer characterizes information about the network layer of this Network Packet. The network layer is one layer from the 7-layer OSI Model. + + + + + Transport layer characterizes information about the transport layer of this Network Packet. The transport layer is one layer from the 7-layer OSI Model. + + + + + + + + + A link layer protocol is a hardware interface protocol, such as Ethernet, or a logical link routing protocol, such as ARP. + + + + + Physical Interface characterizes one hardware interface of a link layer connection. + + + + + Logical Protocols characterizes the logical protocol of a link layer connection. One example of a logical protocol is ARP. + + + + + + + Multiple interface types exist - only most common (Ethernet) included now. Others will be added later as needed. + + + + + Ethernet sends network packets from the sending host to one or more receiving hosts. (REF: IEEE 802.3; http://wiki.wireshark.org/Ethernet) + + + + + + + Logical Protocols characterizes the logical protocol of a link layer connection. One example of a logical protocol is ARP. + + + + + ARP is a logical protocol used for resolution of network layer addresses (e.g., IP addresses) into link layer addresses (e.g., MAC addresses). RARP is a logical protocol used by a host computer to request its network layer address when it has its link layer address. + + + + + Neighbor Discovery Protocol (NDP) is used with IPv6 to determine the link-layer addresses for neighbors. Corresponds to combination of IPv4 protocols: ARP, ICMP Router Discovery, and ICMP Redirect. + + + + + + + Ethernet sends network packets from the sending host to one or more receiving hosts. (REF: IEEE 802.3; http://wiki.wireshark.org/Ethernet) + + + + + The ethernet header includes information such as source MAC address, destination MAC address, and more. + + + + + + + Ethernet header characterizes and ethernet header and includes information such as source MAC address, destination MAC address, and more. + + + + + Destination MAC Addr characterizes the destination MAC Address of the ethernet frame. + + + + + Source MAC Addr characterizes the source MAC Address of the ethernet frame. + + + + + Type or Length characterizes either the length of the ethernet frame or the protocol type of the network layer. + + + + + Checksum characterizes the Frame Check sequence of an ethernet frame. + + + + + + + 0-1500 then it is a length field. Otherwise, it defines the protocol type of the Internet layer. + + + + + Length characterizes the length of the ethernet frame. + + + + + two-octet field in an Ethernet frame. specifies protocol encapsulated in the payload of ethernet frame. + + + + + + + The Address Resolution Protocol is a request and reply protocol that runs encapsulated by the line protocol. It is communicated within the boundaries of a single network, never routed across internetwork nodes. This property places ARP into the Link Layer. It is encapsulated. REF: http://www.comptechdoc.org/independent/networking/guide/netarp.html + + + + + Characterizes the type of hardware address specified in an ARP message. + + + + + ProtoAddrType characterizes the type of protocol address being mapped. For IPv4 addresses, value = 0x0800. + + + + + Harware_Addr_Size represents the byte size of the hardware address. For Ethernet or other IEEE 802 MAC addresses, the value is 6. + + + + + Proto_Addr_Size represents the byte size of the protocol address. IPv4 addresses = 4. + + + + + Op_Type characterizes the type of operation. 1 = ARP request, 2=ARP reply, 3=RARP request, 4=RARP reply. + + + + + Sender_Hardware_Addr characterizes the sender's hardware address (e.g., MAC address). + + + + + Sender_Protocol_Addr characterizes the sender's IP address. + + + + + Recip_Sender_Hardware Addr characterizes the recipients's hardware address (e.g., MAC address). + + + + + Recip Protocol Addr characterizes the recipient's IP address. + + + + + + + ARPOpType specifies types of ARP operations, via a union of the ARPOpTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + ARPOpTypeEnum contains the various ARP Operation Types. + + + + + Indicates the ARP request operation, or value 1 in the OPER field of an ARP packet. + + + + + Indicates the ARP reply operation, or value 2 in the OPER field of an ARP packet. + + + + + Indicates the RARP request operation, or value 3 in the OPER field of an ARP packet. + + + + + Indicates the RARP reply operation, or value 4 in the OPER field of an ARP packet. + + + + + + + NDP Type characterizes NDP (Neighbor Discover Protocol) IPv6 packets. NDP defines five ICMPv6 packet types. RFC 2461: http://tools.ietf.org/html/rfc4861 + + + + + + + + ICMPv6 Header characterizes an ICMPv6 header. + + + + + + Hosts send Router Solicitations in order to prompt routers to generate Router Advertisements quickly (type=133; code=0). + + + + + Routers send out Router Advertisement messages periodically, or in response to Router Solicitations (type=134; code=0). + + + + + Nodes send Neighbor Solicitations to request the link-layer address of a target node while also providing their own link-layer address to the target. Neighbor Solicitations are multicast when the node needs to resolve an address and unicast when the node seeks to verify the reachability of a neighbor (type=135; code=0). + + + + + A node sends Neighbor Advertisements in response to Neighbor Solicitations and sends unsolicited Neighbor Advertisements in order to (unreliably) propagate new information quickly (type=136; code=0). + + + + + Routers send Redirect packets to inform a host of a better first-hop node on the path to a destination. Hosts can be redirected to a better first-hop router but can also be informed by a redirect that the destination is in fact a neighbor. The latter is accomplished by setting the ICMP Target Address equal to the ICMP Destination Address (type=137; code=0). + + + + + + + + Hosts send Router Solicitations in order to prompt routers to generate Router Advertisements quickly.(type=133; code=0) + + + + + Router Solicitation messages include zero or more options, some of which may appear multiple times in the same message. + + + + + + + Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message. + + + + + Src Link Addr characterizes the Source Link-Layer Address option. + + + + + + + Routers send out Router Advertisement messages periodically, or in response to Router Solicitations. (type=134; code=0) + + + + + 8-bit unsigned integer. The default value that should be placed in the Hop Count field of the IP header for outgoing IP packets. A value of zero means unspecified (by this router). + + + + + 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The field can contain values up to 65535 and receivers should handle any value, while the sending rules in Section 6 limit the lifetime to 9000 seconds. + + + + + 32-bit unsigned integer. The time, in milliseconds, between retransmitted Neighbor Solicitation messages. Used by address resolution and the Neighbor Unreachability Detection algorithm. A value of zero means unspecified (by this router). + + + + + 32-bit unsigned integer. The time, in milliseconds, between retransmitted Neighbor Solicitation messages. Used by address resolution and the Neighbor Unreachability Detection algorithm. A value of zero means unspecified (by this router) + + + + + Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message. + + + + + + 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol. If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information. + + + + + 1-bit "Other configuration" flag. When set, it indicates that other configuration information is available via DHCPv6. Examples of such information are DNS-related information or information on other servers within the network. + + + + + + Router Advertisement messages include zero or more options, some of which may appear multiple times in the same message. + + + + + Src Link Addr characterizes the Source Link-Layer Address option. + + + + + 32-bit unsigned integer. The recommended MTU for the link. + + + + + Prefix Info characterizes Prefix Information for Router Advertisement Options. + + + + + + + Nodes send Neighbor Solicitations to request the link-layer address of a target node while also providing their own link-layer address to the target. Neighbor Solicitations are multicast when the node needs to resolve an address and unicast when the node seeks to verify the reachability of a neighbor. (type=135; code=0) + + + + + The IP address of the target of the solicitation. + + + + + Neighbor Solicitation messages include zero or more options, some of which may appear multiple times in the same message. + + + + + + + Neighbor Solicitation messages include zero or more options, some of which may appear multiple times in the same message. + + + + + Src Link Addr characterizes the Source Link-Layer Address option. + + + + + + + A node sends Neighbor Advertisements in response to Neighbor Solicitations and sends unsolicited Neighbor Advertisements in order to (unreliably) propagate new information quickly. (type=136; code=0) + + + + + The IP address of the target of the advertisement. + + + + + Neighbor Advertisement messages include zero or more options, some of which may appear multiple times in the same message. + + + + + + Router flag. When set, the R-bit indicates that the sender is a router. The R-bit is used by Neighbor Unreachability Detection to detect a router that changes to a host. + + + + + Solicited flag. When set, the S-bit indicates that the advertisement was sent in response to a Neighbor Solicitation from the Destination address. The S-bit is used as a reachability confirmation for Neighbor Unreachability Detection. + + + + + Override flag. When set, the O-bit indicates that the advertisement should override an existing cache entry and update the cached link-layer address. + + + + + + Neighbor Advertisement messages include zero or more options, some of which may appear multiple times in the same message. + + + + + Target Link Addr characterizes the Target Link-Layer Address option. + + + + + + + Routers send Redirect packets to inform a host of a better first-hop node on the path to a destination. Hosts can be redirected to a better first-hop router but can also be informed by a redirect that the destination is in fact a neighbor. The latter is accomplished by setting the ICMP Target Address equal to the ICMP Destination Address. (type=137; code=0) + + + + + An IP address that is a better first hop to use for the ICMP Destination Address. + + + + + The IP address of the destination that is redirected to the target. + + + + + Redirect messages include zero or more options, some of which may appear multiple times in the same message. + + + + + + + Redirect messages include zero or more options, some of which may appear multiple times in the same message. + + + + + The linnk-layer address for the target. + + + + + As much as possible of the IP packet that triggered the sending of the Redirect message without making the redirect packet exceed the minimum MTU specified in the IPv6 protocol. + + + + + + + Src Link Addr characterizes the Source Link-Layer Address option. (type=1) + + + + + The length of the option (including the type and length fields) in units of 8 octets. + + + + + The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. + + + + + + + Target Link Addr characterizes the Target Link-Layer Address option. (type=2) + + + + + The length of the option (including the type and length fields) in units of 8 octets. + + + + + The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. + + + + + + + Prefix Info characterizes Prefix Information for Router Advertisement Options. It provides hosts with on-link prefixes and prefixes for Address Autoconfiguration. (type=3). RFC 4861. + + + + + Length characterizes the length of the option (the number of valid leading bits in the prefix), and is represented as a 32-bit integer. + + + + + 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. The prefix length field provides necessary information for on-link determination (when combined with the L flag in the prefix information option). + + + + + 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xffffffff) represents infinity. + + + + + 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that addresses generated from the prefix via stateless address autoconfiguration remain preferred. + + + + + The Prefix is an IP address or a prefix of an IP address. + + + + + + 1-bit on-link flag. When set, indicates that this prefix can be used for on-link determintation. When not set the advertisement makes no statement about on-link or off-link properties of the prefix. + + + + + 1-bit autonomous address-configuration flag. When set indicates that this prefix can be usd for stateless address configuration. + + + + + + The redirected header option is used in redirect messages and contains all or part of the packet that is being redirected. (type=4) + + + + + The length of the option (including the type and length fields) in units of 8 octets. + + + + + As much as possible of the IP packet that triggered the sending of the redirect without making redirect packet larger than MTU. + + + + + + + The MTU option is used in Router Advertisement messages to ensure that all nodes on a link use the same MTU value in those cases where the link MTU is not well known. (type=5). + + + + + The length of the MTU option type: length=1. + + + + + The recommended MTU for the link. 32-bit unsigned integer. + + + + + + + The Internet layer is the group of methods, protocols, and specifications that are used to transport packets from the origiating host across network boundaries. Not all protocols are currently defined, just those most commonly used: IPv4, ICMPv4, IPv6, ICMPv6. Other protocols will be added as needed. (http://en.wikipedia.org/wiki/Internet_layer) + + + + + Internet Protocol version 4 (IPv4) is a connectionless protocol for use on packet-switched link layer networks (e.g., Ethernet). + + + + + ICMP is chiefly used the the operating systems of networked computers to send error messages indicating, for example, that a requested serivce is not available or that a host or router could not be reached (http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol; REF: http://www.networksorcery.com/enp/protocol/icmp.htm). + + + + + Internet Protocol version 6 (IPv6) is intended to succeed IPv4, and like IPv4 it is a connectionless protocol for use on packet-switched link layer networks. + + + + + ICMPv6 is the implementation of the ICMP for INv6. ICMPv6 performs error reporting and diagnostic functions. + + + + + + + Internet Protocol version 4 (IPv4) is a connectionless protocol for use on packet-switched link layer networks (e.g., Ethernet). REF: RFC 791; http://en.wikipedia.org/wiki/IPv4. + + + + + The IPv4 header provides addressing, and internet modules use fields in the header to fragment and reassemble internet datagrams when necessary for transmission through small packet networks. + + + + + The data portion of an IP packet is interpreted based on the value of the Protocol header field. Actual field values will probably be specified in the elements of the different network layers, but we provide a field here to capture any data as necessary. + + + + + + + The IPv4 header provides addressing, and internet modules use fields in the header to fragment and reassemble internet datagrams when necessary for transmission through small packet networks. REF: RFC 791. + + + + + The version field indicates the format of the internet header. For IP v4, the version is 4. + + + + + The Internet Header Length specifies the length of IP packet header in 32 bit words. Min value = 5. + + + + + Originally defined as the Type of Service field, the Differentiated Services Code Point (DSCP) field is now defined by RFC 2474 for Differentiated services (DiffServ). New technologies are emerging that require real-time data streaming and therefore make use of the DSCP field. An example is Voice over IP (VoIP), which is used for interactive data voice exchange (http://en.wikipedia.org/wiki/IPv4). + + + + + Explicit Congestion Notification: This field is defined in RFC 3168 and allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that is only used when both endpoints support it and are willing to use it. It is only effective when supported by the underlying network. (http://en.wikipedia.org/wiki/IPv4). + + + + + This 16-bit field defines the entire datagram size, including header and data, in bytes. + + + + + The Identification field is primarily used for uniquely identifying fragments of an original IP datagram. (http://en.wikipedia.org/wiki/IPv4) + + + + + This is a three-bit field used to control or identify fragments. An field has been defined for each bit with associated enumerated types. + + + + + The fragment offset field is 13 bits long and specifies the offset of a particular fragment relative to the beinnng of the original unfragmented IP datagram. http://en.wikipedia.org/wiki/IPv4 + + + + + This 8-bit field helps prevent datagrams from persisting on an internet (it limits a datagram's lifetime). + + + + + This field defines the protocol used in the data portion of the IP datagram. The type of this field is an enumerated list of IP protocol numbers as maintained by the Internet Assigned Numbers Authority. + + + + + This field is a 16-bit checksum used for error-checking of the header. + + + + + This field is the IPv4 address of the sender of the packet. + + + + + This field is the IPv4 address of the receiver of the packet. + + + + + + The IPv4 option field is variable in length with zero or more options. It is not often used. http://en.wikipedia.org/wiki/IPv4 + + + + + + + + These flag types are used to control or identify fragments in an IP packet. It is a three-bit field, each of the three bits are defined by a field with a string value that indicates the meaning of whether or not the bit is set. + + + + + Bit 0: This bit value (0) is reserved and must be zero. + + + + + Bit 1: This is the "don't fragment" bit. Values are specified in the DoNotFragmentType. + + + + + Bit 2: This is the "more fragments" bit. Values are specified in the MoreFragmentsType. + + + + + + + DoNotFragmentType specifies fragmenting options, via a union of the DoNotFragmentTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + This type enumerates the meaning of the Do Not Fragment bit used in IPv4 flags. + + + + + Indicates that the router or other device should fragment the packet if necessary, especially if the packet size is bigger than the MTU of an outgoing interface. + + + + + Indicates that the router or other device should NOT fragment the packet in any circumstance. + + + + + + + MoreFragmentsType specifies whether there are more fragments, via a union of the MoreFragmentsTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + This type enumerates the meaning of the More Fragments bit used in IPv4 flags. + + + + + Indicates that the last fragment has been received. In other words, the "more fragments" flag is set to 0. + + + + + Indicates that more fragments need to be received. In other words, the "more fragments" flag is set. + + + + + + + The IPv4 option field is variable in length with zero or more options. + + + + + The copied flag indicates that this option is copied into all fragments on fragmentation. 1 bit. They are represented in this field by a string which specifies their value. + + + + + The option class is represented by 2 bits where 0 = control; 1 = reserved for future use; 2 = debugging and measurement; 3 = reserved for future use. These enumerated values are defined for this field. + + + + + The Internet Protocol has provision for optional header fields indeitified by an option type. These types are enumerated in the IPv4OptionsType. + + + + + + + IPv4CopyFlagType specifies value of IPv4 copy flag, via a union of the IPv4CopyFlagTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The copy flag indicates whether the option is copied into all fragments on fragmentation (0=not copied; 1=copied). This information is also captured in the IPv4OptionsTypeEnum which lists all options, which incorporates copy and class numbers. + + + + + Indicates that the options need NOT be copied into all fragments of a fragmented packet. + + + + + Indicates that the options need to be copied into all fragments of a fragmented packet. + + + + + + + IPv4ClassType specifies IPv4 class type, via a union of the IPv4ClassTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The option class is represented by 2 bits. The explicit meanings are captured here in an enumerated list. This information is also captured in the IPv4OptionsTypeEnum which lists all options, which incorporates copy and class numbers. + + + + + Indicates the "control" options. + + + + + Indicates a reserved value. + + + + + Indicates the debugging and measurement options. + + + + + Indicates a reserved value. + + + + + + + IPv4OptionsType specifies IPv4 options, via a union of the IPv4OptionsTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The Internet Protocol (IP) has provision for optional header fields identified by an option type field. Options 0 and 1 are exactly one octet which is their type field. All other options have their one octet type field, followed by a one octet length field, followed by length-2 octets of option data. The option type field is sub-divided into a one bit copied flag, a two bit class field, and a five bit option number. These taken together form an eight bit value for the option type field. IP options are commonly refered to by this value. The IPv4OptionsEnum enumerates the options numbers that can be applied in IP. See http://www.iana.org/assignments/ip-parameters for more information. + + + + + Indicates the End of Options List option, or EOOL. + + + + + Indicates the No Operation option, or NOP. + + + + + Indicates the Security option, or SEC. + + + + + Indicates the Loose Source Route option, or LSR. + + + + + Indicates the Time Stamp option, or TS. + + + + + Indicates the Extended Security option, or E-SEC. + + + + + Indicates the Commercial Security option, or CIPSO. + + + + + Indicates the Record Route option, or RR. + + + + + Indicates the Stream ID option, or SID. + + + + + Indicates the Strict Source Route option, or SSR. + + + + + Indicates the Experimental Measurement option, or ZSU. + + + + + Indicates the MTU probe option, or MTUP. + + + + + Indicates the MTU reply option, or MTUR. + + + + + Indicates the Experimental Flow Control option, or FINN. + + + + + Indicates the Experimental Access Control option, or FINN. + + + + + + + + + + Indicates the IMI Traffic Descriptor option, or IMITD. + + + + + Indicates the Extended Internet Protocol option, or EIP. + + + + + Indicates the Trace Route option, or TR. + + + + + Indicates the Address Extension option, or ADDEXT. + + + + + Indicates a Router Alert option, or RTRALT. + + + + + Indicates a Selective Directed Broadcast option, or SDB. + + + + + Indicates the Dynamic Packet State option, or DPS. + + + + + Indicates the Upstream Multicast Packet option, or UMP. + + + + + Indicates the Quick-Start option, or QS. + + + + + Indicates the RFC3692-style Experiment option, or EXP. + + + + + + + Internet Protocol version 6 (IPv6) is intended to succeed IPv4, and like IPv4 it is a connectionless protocol for use on packet-switched link layer networks. RFC 3513, RFC 2460, http://en.wikipedia.org/wiki/IPv6. + + + + + IPv6 headers is a simplification of the IPv4 header. + + + + + + In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper-layer header in a packet. http://tools.ietf.org/html/rfc2460 + + + + + + + + The IPv6 header is a simplification of the IPv4 header. + + + + + 4-bit Internet Protocol version number =6. + + + + + 8-bit traffic class field. Available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets. http://tools.ietf.org/html/rfc2460#section-7 + + + + + 20-bit flow label. Used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service. http://tools.ietf.org/html/rfc2460#section-6. + + + + + 16-bit unsigned integer. Length of the IPv6 payload (the rest of the packet following the IPv6 header) in octets. Any extension headers are considered part of the payload. + + + + + 8-bit selector. Identifies the type of header immediately following the IPv6 header. Uers the same values as the IPv4 protocol field. + + + + + TTL/hop limit specifies how many times a packet can be forwarded. 8-bit unsigned integer. + + + + + 128-bit address of the originator of the packet. + + + + + 128-bit address of the intended recipient of the packet. + + + + + + + In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper-layer header in a packet. An IPv6 packet may carry zero, one, or more extension headers, each identified by the Next Header field of the preceding header. http://tools.ietf.org/html/rfc2460 + + + + + The Hop-by-Hop Options header is used to carry optional information that must be examined by every node along a packet's delivery path. It carries a variable number of type-length-value (TLV) encoded options. + + + + + The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination. http://tools.ietf.org/html/rfc2460 + + + + + The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU. A fragment packet begins with an unfragmentable part consisting of the IPv6 header plus all extension headers up to and including the routing header. We don't include it for this field because the data is already stored in other elements. We provide the elements necessary for the Fragmentable Part. http://tools.ietf.org/html/rfc2460 + + + + + The Destination Options header is used to carry optional information that needs to be examined only by a packet's destination node(s). + + + + + Follows RFC2402. The IP Authentication Header is used to provide connectionless integrity and data origin authentication for IP datagrams and to provide protection against replays. http://www.ietf.org/rfc/rfc2402.txt + + + + + Follows RFC2406. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. + + + + + + + IPv6DoNotRecogActionType specifies possible actions when option is not recognized, via a union of the IPv6DoNotRecogActionTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + Enumerates possible actions when an option is not recognized. + + + + + Indicates that the option should be skipped and the header should continue to be processed. See RFC 2460. + + + + + Indicates that the packet should be discarded. See RFC 2460. + + + + + Indicates that the packet should be discarded and regardless of whether or not the packet's Destination Address was a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. See RFC 2460. + + + + + Indicates that the packet should be discarded and only if the packet's Destination Address was not a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. See RFC 2460. + + + + + + + IPV6PacketChangeType specifies whether a packet has changed, via a union of the IPv6PacketChangeTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + Enumerated list that specifies whether or not the Option Data of an option can change en-route to the packet's final destination. + + + + + Indicates that the packet does not change en-route. See RFC 2460. + + + + + Indicates that the packet may change en-route. See RFC 2460. + + + + + + + Specifies the meaning of each bit of the 8-bit IPv6OptionType type. + + + + + Action to be taken if the processing IPv6 nodes does not recognize the Option Type. This information is internally encoded in the Option Type identifier (higest-order two bits) such that their highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option type. These possible actions are enumerated via IPv6DoNotRecogActionType. + + + + + The third highest order bit of the Option Data specifies whether or not the Option Data of that option can change en-route to the packet's final destination. + + + + + This field may be used to specify the actual Option Type byte, with no explicit meaning attached. Meaning/intrepretation provided by the Do_Not_Recogn_Action and Packet_Change fields. + + + + + + + IPVersionType specifies IP versions, via a union of the IPVersionTypeEnum type and the atomic xs:string type. See http://www.iana.org/assignments/version-numbers/version-numbers.xml for a complete list. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + Enumerates the different Internet Protocol versions. IPv4(4) and IPv6(6) are the most common. + + + + + Indicates IP Version 4. + + + + + Indicates the IP version designating ST Datagram Mode. + + + + + Indicates IP Version 6. + + + + + Indicates the IP version designating TP/IX: The Next Internet. + + + + + Indicates the IP version designating PIP: The P Internet Protocol. + + + + + Indicates the IP version designating TUBA (TCP and UDP with Bigger Addresses, i.e. RFC 1347). + + + + + + + only UDP and TCP defined to begin. Other protocols will be defined as necessary. + + + + + + + + TCP provides reliable, ordered delivery of a stream of bytes from a prograom on one computer to another program on another computer. http://en.wikipedia.org/wiki/Transmission_Control_Protocol + + + + + UDP uses a simple transmission model without implicit handshaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. http://en.wikipedia.org/wiki/User_Datagram_Protocol + + + + + + + TCP provides reliable, ordered delivery of a stream of bytes from a prograom on one computer to another program on another computer. http://en.wikipedia.org/wiki/Transmission_Control_Protocol + + + + + The TCP header contains 10 mandatory fields and an optional extension field. http://en.wikipedia.org/wiki/Transmission_Control_Protocol + + + + + Options have up to three fields: Option-Kind (1 byte), Option-Length (1 byte), Option-Data (variable). This field will be further defined when required. + + + + + The Data field specifies the data payload of the TCP packet. + + + + + + + UDP uses a simple transmission model without implicit handshaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. http://en.wikipedia.org/wiki/User_Datagram_Protocol + + + + + The UDP header consists of four fields, which are defined here. + + + + + The Data field specifies the data payload of the UDP packet. + + + + + + + The TCP header contains 10 mandatory fields and an optional extension field. http://en.wikipedia.org/wiki/Transmission_Control_Protocol + + + + + Identifies the sending port. + + + + + Identifies the receiveing port. + + + + + The Sequence number (32-bits) has a dual role: If the SYN flag is set, then this is the initial sequence numbers. If the SYN flag is clear (see Control Bits element), then this is the accumulated sequence number of the first data byte of this packet for the current session. http://en.wikipedia.org/wiki/Transmission_Control_Protocol + + + + + If the ACK flag (see Control Bits element) is set then the value of this field is the next sequence number that the receiver is expecting. + + + + + Specifies the size of the TCP header in 32-bit words. + + + + + these 3 bits are reserved for future use and should be set to zero. + + + + + The TCP header contains 9 flags (aka Control Bits). + + + + + The size of the receive window, which specifies the number of bytes (beyond the sequence number in the acknowledgment field) that the sender of this segment is currently willing to receive. http://en.wikipedia.org/wiki/Transmission_Control_Protocol + + + + + The 16-bit checksum field is used for error-checking of the header and data. http://en.wikipedia.org/wiki/Transmission_Control_Protocol + + + + + If the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte. http://en.wikipedia.org/wiki/Transmission_Control_Protocol + + + + + + + Defines the 9 different flags in the TCP header. + + + + ECN-nonce concealment protection. + + + + + Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism. http://en.wikipedia.org/wiki/Transmission_Control_Protocol + + + + + ECN-Echo indicates: if the SYN flag is set, that the TCP peer is ECN capable; if the SYN flag is clear, that a packet with Congestion Experienced flag in IP header set is received during normal transmission. http://en.wikipedia.org/wiki/Transmission_Control_Protocol + + + + + Indicates that the Urgent point field is significant. + + + + + indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set. http://en.wikipedia.org/wiki/Transmission_Control_Protocol + + + + + Push functions. asks to push the buffered dtata to the receiving application. http://en.wikipedia.org/wiki/Transmission_Control_Protocol + + + + + Reset the connection. + + + + + Synchronize sequence numbers. Only the first packet sent from each end should have this flag set. http://en.wikipedia.org/wiki/Transmission_Control_Protocol + + + + + If this flag is set, it means there is no more data from sender. + + + + + + The UDP header type defines the four fields in the UDP header. + + + + + Identifies the sender's port. + + + + + Identifies the receiver's port. + + + + + Specifies the length in bytes of the entire datagram (header and data). + + + + + The checksum is used for error-checking of the header and data. + + + + + + + IANAHardwareType specifies the type of hardware, via a union of the IANAHardwareTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + This enumerated type specifies Address Resolution Protocol (ARP) parameters. http://www.iana.org/assignments/arp-parameters/arp-parameters.xml + + + + + Indicates Ethernet hardware. + + + + + Indicates IEEE 802 compliant hardware for networks carrying variable-size packets. + + + + + Indicates the ARCNET LAN protocol. + + + + + Indicates the Frame Relay WAN technology. + + + + + Indicates the ATM (Asynchronous Transfer Mode) networking standard. + + + + + Indicates the HDLC (High-Level Data Link Control) protocol. + + + + + Indicates the FibreChannel technology. + + + + + Indicates the ATM (Asynchronous Transfer Mode) networking standard. + + + + + Indicates the Serial Line protocol, or SLIP. + + + + + + + EtherObjectType specifies "type" field of Ethernets, via a union of the IANAEtherTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + http://cavebear.com/archive/cavebear/Ethernet/type.html http://www.iana.org/assignments/ethernet-numbers http://standards.ieee.org/develop/regauth/ethertype/eth.txt http://en.wikipedia.org/wiki/EtherType + + + + + Indicates the IPv4 Ethernet type is specified. + + + + + Indicates the ARP Ethernet type is specified. + + + + + Indicates the RARP Ethernet type is specified. + + + + + Indicates the IPX Ethernet type is specified. + + + + + Indicates the SNMP Ethernet type is specified. + + + + + Indicates the IPv6 Ethernet type is specified. + + + + + + + IANAAssignedIPNumbersType specifies Internet Protocol numbers, via a union of the IANAAssignedIPNumbersTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + Assigned Internet Protocol Numbers http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml List of protocol numbers used in the Protocol fields of the IPv4 header and the Next Header of the IPv6 header. + + + + + Indicates the IPv6 Hop-By-Hop option protocol (HOPOPT). + + + + + Indicates the Internet Control Message protocol (HOPOPT). + + + + + Indicates the Internet Control Message protocol (HOPOPT). + + + + + Indicates the Gateway-to-Gateway protocol (HOPOPT). + + + + + Indicates the IPv4 Encapsulation protocol (IPv4). + + + + + Indicates the Stream protocol (HOPOPT). + + + + + Indicates the TCP protocol. + + + + + Indicates the EGP (Exterior Gateway) protocol. + + + + + Indicates the IGP/IGRP (Cisco) protocol. + + + + + Indicates the Network-Voice protocol. + + + + + Indicates the PUP protocol. + + + + + Indicates the ARGUS protocol. + + + + + Indicates the EMCON protocol. + + + + + Indicates the Cross Net Debugger protocol. + + + + + Indicates the UDP protocol. + + + + + Indicates the IPv6 protocol. + + + + + Indicates the Source Demand Routing protocol. + + + + + Indicates the routing header for IPv6. + + + + + Indicates the fragment header for IPv6. + + + + + Indicates the Reservation Protocol. + + + + + Indicates the General Routing Encapsulation protocol number. + + + + + Indicates the Encapsulated Security Payload protocol number. + + + + + Indicates the Authentication Header protocol number. + + + + + Indicates the ICMP for v6 protocol number. + + + + + Indicates the No Next Header for IPv6 protocol number. + + + + + Indicates the Destination Options for IPv6 protocol number. + + + + + Indicates the Mobility Header protocol number. + + + + + + + IANAPortNumberRegistryType specifies port numbers, via a union of the IANAPortNumberRegistryTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml + + + + + Indicates the port for ftpdata. + + + + + Indicates the port for ftp. + + + + + Indicates the port for ssh. + + + + + Indicates the port for telnet. + + + + + Indicates the port for smtp. + + + + + Indicates the domain port. + + + + + Indicates the port for tftp. + + + + + Indicates the port for http. + + + + + Indicates the port for ldap. + + + + + Indicates the port for https. + + + + + + + ICMP is used to send error messages (e.g., a datagram cannot reach its destination), informational messages ( e.g., timestamp information), or a traceroute message. REF: http://www.networksorcery.com/enp/protocol/icmp.htm + + + + + Actual header bytes are captured here. The message content of each type/code pair is also defined as part of the larger, complex "ICMPv4PacketType" type as either an error message, an informational message, or a traceroute message. The meaning of the type and code bytes is made explicit in the elements corresponding to each message type. + + + + + + + + + For ICMP error messages, boolean values are used in this field to explicitly interpret the type and code bytes appearing in the ICMP header. Additional fields and message content are also defined here. + + + + + For ICMP informational messages, boolean values are used in this field to explicitly interpret the type and code bytes appearing in the ICMP header. Additional fields and message content are also defined here. + + + + + For ICMP traceroute messages (type = 30), specifies related fields and ICMP code value. A boolean value is used to explicitly interpret the code byte appearing in the ICMP header. Additional fields and message content are also defined here. + + + + + + + + Actual ICMP header bytes are defined, corresponding to the ICMP type, ICMP code, and to the checksum. + + + + + ICMP Type byte specifies the format of the ICMP message. + + + + + ICMP Code byte further qualifies the ICMP message. + + + + + ICMP Checksum (16 bits) covers the ICMP message. + + + + + + + ICMP error messages include destination unreachable messages, source quench messages, redirect messages, and time exceeded messages. + + + + + + A destination unreachable message is an ICMP message which is generated by the host or its inbound gateway to inform the client that the destiation is unreachable for some reason (http://en.wikipedia.org/wiki/ICMP_Destination_Unreachable). + + + + + A source quench message is an ICMP message that requests that the sender decrease the rate of messages sent to a router or host. This message may be generated if a router or host does not have sufficient buffer space to process the request or may occur if the router or host buffer is approaching its limit (http://en.wikipedia.org/wiki/ICMP_Source_Quench). + + + + + A redirect message is used to send data packets on an alternative route. This ICMP redirect message informs a host to update its routing information. + + + + + An ICMP time exceeded message is generated by a gateway to inform the source of a datagram that the datagram has been discarded due to the time to live field reaching zero. A time exceeded message may also be sent by a host if it fails to reassemble a fragmented datagram within its time limit (http://en.wikipedia.org/wiki/ICMP_Time_Exceeded). + + + + + + Message content common to all ICMP error messages are defined here. Fields that are specific to individual messages are defined separately under each message type. + + + + + + + Elements associated with ICMPv4 error messages (as opposed to ICMP informational messages or ICMP traceroute message). + + + + + IP header from the original datagram. + + + + + First 8 bytes of the original datagram's data. + + + + + + + ICMP informational messages include echo request/reply, timestamp request/reply, and address mask request/reply. + + + + + + Echo reply/request messages are also known as "ping". The Info_Message_Content field contains an identifier and sequence number which together form the "quench" for echo reply and echo request. Fields specific to an echo reply message are given as elements to this echo reply field (type=0). + + + + + Echo reply/request messages are also known as "ping". The Info_Message_Content field contains an identifier and sequence number which together form the "quench" for echo reply and echo request. Fields specific to an echo request message are given as elements to this echo request field (type=8). + + + + + A timestamp request is an ICMP informational message used for time synchronization. + + + + + A timestamp reply is an informational ICMP message which replies to a timestamp request message. + + + + + An address mask request is an ICMP informational message (query message) normally sent by a host to a router in order to obtain an appropriate subnet mask (type=17). + + + + + An address mask reply is an ICMP informational message, used to reply to an address mask request message with an appropriate subnet mask (type=18). + + + + + + Fields that are common to all ICMP informational messages are defined here. Fields that are specific to individual messages are defined separately under each message type. + + + + + + + Elements associated with ICMPv4 informational messages (as opposed to ICMP error messages or ICMP traceroute message). + + + + + 16-bit identifier. Combined with the sequence number, called the "quench" for echo reply and echo request. + + + + + 16-bit sequence number. The identifier and sequence number can be used by the client to match the reply with the request that caused the reply. + + + + + + + Elements associated with ICMPv4 traceroute message (as opposed to ICMP error messages or ICMP informational messages); corresponds to ICMP type =30. (http://www.networksorcery.com/enp/protocol/icmp/msg30.htm) + + + + + + One of two possible subtypes for an ICMP traceroute message. This subtype means that the outbound packet was successfully forwarded (code=0). + + + + + One of two possible subtypes for an ICMP traceroute message. This one means that there is no route for the outbound packet and the packet was discarded (code=1). + + + + + + 16 bits. The ID number as copied from the ICMP traceroute option of the packet which caused this traceroute message to be sent (not related to the ID number in the IP header). (http://www.networksorcery.com/enp/protocol/icmp/msg30.htm) + + + + + 16 bits. Outbound hop count as copied from the IP traceroute option of the packet which caused this traceroute message to be sent (http://www.networksorcery.com/enp/protocol/icmp/msg30.htm). + + + + + 16 bits. Return hop count as copied from the IP traceroute options of the packet which caused this traceroute message to be sent. (http://www.networksorcery.com/enp/protocol/icmp/msg30.htm) + + + + + 32 bits. The speed in bytes per second of the link over which the Outbound/Return Packet will be sent. If this value cannot be determined, the field should be set to zero. (http://www.networksorcery.com/enp/protocol/icmp/msg30.htm) + + + + + 32 bits. The MTU in bytes of the link over which the Outbound/Return Packet will be sent. MTU refers to the data portion (includes IP header; excludes datalink header/trailer) of the packet. If this value cannot be determined, this field should be set to zero. (http://www.networksorcery.com/enp/protocol/icmp/msg30.htm) + + + + + + + ICMP is used to send error messages (e.g., a datagram cannot reach its destination), informational messages ( e.g., ping). Only the message types defined in RFC 4443 (ICMP v6) are included; additional message types will be defined as needed. REF: http://tools.ietf.org/html/rfc4443 and http://www.networksorcery.com/enp/protocol/icmpv6.htm and http://en.wikipedia.org/wiki/ICMPv6. + + + + + Actual ICMP v6 header bytes are defined, corresponding to the ICMP type, ICMP code, and to the checksum. + + + + + + For ICMP v6 error messages, boolean values are used in this field to explicitly interpret the type and code bytes appearing in the ICMP header. Additional fields and message content are also defined here. The type value indicates whether an ICMP message is an error message (type is 0 to 127) or an information message (type is 128 to 255). + + + + + For ICMP v6 informational messages, boolean values are used in this field to explicitly interpret the type and code bytes appearing in the ICMP header. Additional fields and message content are also defined here. The type value indicates whether an ICMP message is an error message (type is 0 to 127) or an information message (type is 128 to 255). + + + + + + + + Actual ICMP header bytes are defined, corresponding to the ICMP type, ICMP code, and to the checksum. Translation of each type and code byte are defined in text by using boolean values associated with corresponding elements in the informational and error message type elements. + + + + + The ICMP v6 type byte specifies the type of the message. Values range from 0 to 127 (high order bit is 0) indicate an error messages; values from 128 to 255 (high order bit is 1) indicate an informational message. + + + + + The code byte value depends on the message type and provides an additional level of message granularity. + + + + + Checksum characterizes the checksum information of an ICMPv6 header. + + + + + + + ICMP v6 error messages include destination unreachable messages, packet too big messages, and time exceeded messages, and parameter problem messages, as defined in RFC 2463. Type values of ICMP v6 error messages range from 1 to 127. + + + + + + A destination unreachable message should be generated by a router, or by the IPv6 later in the originating node, in response to a packet that cannot be delivered to its destination address for reasons other than congestion. (http://tools.ietf.org/html/rfc4443) + + + + + A packet too big message must be sent by a router in response to a packet that it cannot forward because the packet is larger than the MTU of the outgoing link. + + + + + A time exceeded message is send if either the hop limit is exceeded (hop limit = 0) or if fragment reassembly has timed out. + + + + + If an IPv6 node processing a packet finds a problem with a field in the IPv6 header or extension headers and it cannot complete processing of the packet, it should send an ICMPv6 Parameter Problem message to the packet's source (http://tools.ietf.org/html/rfc4443). + + + + + + as much of invoking packet as possible without the ICMPv6 packet exceeding the minimum IPc6 MTU + + + + + + + ICMP v6 informational messages include echo request/reply; other informational message types will be added in the future as they are more commonly used (only echo request/reply are defined in RFC 4443). + + + + + + Echo request and reply messages are used for diagnostic purposes. + + + + + Echo request and reply messages are used for diagnostic purposes + + + + + + ields that are common to all ICMP v6 informational messages are defined here. Fields that are specific to individual messages are defined separately under each message type. + + + + + + + Elements associated with ICMPv6 informational messages (as opposed to ICMP v6 error messages). + + + + + 16-bit identifier. Combined with the sequence number, called the "quench" for echo reply and echo request. + + + + + 16-bit sequence number. The identifier and sequence number can be used by the client to match the reply with the request that caused the reply. + + + + + + + Echo reply v4 informational message (used to ping); ICMP type=0. + + + + + + Echo reply is the only subtype (code=0). + + + + + + This data is optional and is used for the different kind of answers given with an ICMP Echo Reply message. Can be arbitrary length (but less than the MTU of the network). + + + + + + + Destination Unreachable error message; ICMP type=3. + + + + + One of 16 different subtypes of a destination unreachable ICMP message; destination network unreachable (code=0). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; destination host unreachable (code=1). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; destination protocol unreachable (code=2). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; destination port unreachable (code=3). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; fragmentation required (code=4). This field has an additional field (Next-Hop MTU), as well as a boolean value indicating this subtype. + + + + + One of 16 different subtypes of a destination unreachable ICMP message; source route failed (code=5). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; destination network unknown (code=6). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; destination host unknown (code=7). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; source host isolated (code=8). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; host administratively prohibited (code=9). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; host administratively prohibited (code=10). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; network unreachable for TOS (code=11). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; host unreachable for TOS (code=12). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; communication administratively prohibited (code=13). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; host precedence violation (code=14). + + + + + One of 16 different subtypes of a destination unreachable ICMP message; precedence cutoff in effect (code=15). + + + + + + + This further specifies an ICMP destination unreachable (type=3) message of code=4 (fragmentation required) message by providing a Next-Hop MTU field. + + + + + Indicates that the subtype of the destination unreachable ICMP message is "fragmentation required". + + + + + The Next-Hop MTU field contains the MTU of the next-hop network is a code 4 error (fragmentation required) occurs. + + + + + + + Source Quench (congestion control) error message; ICMP type=4. + + + + + Source quench is the only subtype (code=0). + + + + + + + Redirect Message error message; ICMP type=5. + + + + + + One of 4 different subtypes of a redirect ICMP message; redirect datagram for the network (code=0). + + + + + One of 4 different subtypes of a redirect ICMP message; redirect datagram for the host (code=1). + + + + + One of 4 different subtypes of a redirect ICMP message; redirect datagram for the TOS and network (code=2). + + + + + One of 4 different subtypes of a redirect ICMP message; redirect datagram for the TOS and host (code=3). + + + + + + The IP address is the 32-bit address of the gateway to which the redirection should be sent. + + + + + + + Echo Request informational message (used to ping); ICMP type=8. + + + + + + Echo request is the only subtype (code=0). + + + + + + This data is optional and is used for the different kind of answers given with an ICMP Echo Request message. Can be arbitrary length (but less than the MTU of the network). + + + + + + + Time Exceeded error message; ICMP type=11. + + + + + specifies that the time-to-live was exceeded in transit (code=0). + + + + + specifies that the fragment reassembly time was exceeded (code=1). + + + + + + + Time Stamp Request informational message; ICMP type=13. + + + + + + This is the only subtype of a timestamp request message (code=0). + + + + + + 32-bits; number of ms since midnight UT. The originate timestamp is the time the sender last touched the message before senting it. If the time is not available in milliseconds or cannot be provided with respect to midnight UT, then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value. + + + + + + + Time Stamp Reply informational message; ICMP type=14. + + + + + + This is the only subtype of a timestamp reply message (code=0). + + + + + + The originate timestamp is the time the sender last touched the message before senting it. If the time is not available in milliseconds or cannot be provided with respect to midnight UT, then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value. + + + + + The receive timestamp is the time the echoer first touched the message on receipt. If the time is not available in milliseconds or cannot be provided with respect to midnight UT, then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value. + + + + + The transmit timestamp is the time the echoer last touched the message on sending it. If the time is not available in milliseconds or cannot be provided with respect to midnight UT, then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value. + + + + + + + Address Mask Request informational message; ICMP type=17. + + + + + + This is the only possible subtype of an address mask request message (code=0). + + + + + + The address mask can be set to 0 in an address mask request message (as opposed to an address mask reply message, in which case it should be set to the subnet mask). + + + + + + + Address Mask informational message; ICMP type=18. + + + + + + This is the only possible subtype of an address mask reply message (code=0). + + + + + + This address mask field should be set to the subnet mask. + + + + + + + Destination unreachable error message; ICMP v6 type=1. + + + + + No route to destination (ICMP v6 code=0). + + + + + Communication with destination administratively prohibited (ICMP v6 code=1). + + + + + Beyond scope of source address (ICMP v6 code =2). + + + + + Address is unreachable (ICMP v6 code=3). + + + + + Port is unreachable (ICMP v6 code=4). + + + + + Source address failed ingress/egress policy (ICMP v6 code=5). + + + + + Reject route to destination (ICMP v6 code=6). + + + + + + + Packet too big error message; ICMP v6 type=2. + + + + + + Only one code value is defined and is set to 0 (zero) by the originator and ignored by the receiver. + + + + + + Maximum Transmission Unit describes the size limit for any given physical network. + + + + + + + Time exceeded error message; ICMP v6 type=3. + + + + + Hop limit exceeded in transit (ICMP v6 code=0). + + + + + Fragment reassembly time exceeded (ICMP v6 code=1). + + + + + + + Parameter problem error message; ICMP v6 type=4. + + + + + + Erroneous header field encountered (ICMP v6 code=0). + + + + + Unrecognized next header type encountered (ICMP v6 code=1). + + + + + Unrecognized IP v6 option encountered (ICMP v6 code=2). + + + + + + identifies octet offset within invoking packet where error was detected. + + + + + + + Echo request informational ICMP v6 message; type=128. + + + + + + Every node must implement an ICMP v6 Echo responder function that receives Echo Requests (ICMP v6 code=0). + + + + + + Zero or more octets of arbitrary data. + + + + + + + Echo reply informational ICMP v6 message; type=129. + + + + + + Every node must implement an ICMP v6 Echo responder function that originates corresponding Echo Replies(ICMP v6 code=0). + + + + + + This is the data from the invoking echo request message. + + + + + + + Provides an IP address or a prefix of an IP address for NDP for IPv6. + + + + + IPv6 address + + + + + The initial bits of an IPv6 address (these are identical for all hosts in a network) form the network's prefix. http://ipv6.com/articles/general/IPv6-Addressing.htm + + + + + + + Defines fields for the IPv6 Hop-by-Hop Options header which is used to carry optional information that must be examined by every node along a packet's delivery path. + + + + + Identifies the type of header immediately following the Hop-by-Hop Options header. Uses the same values as the IPv4 Protocol field. + + + + + Length of the Hop-by-Hop Options header in 8-octet units, not including the first 8 octets. + + + + + Variable-length field, of length such that the complete Hop-by-Hop Options header is an integer multiple of 8 octets long. Contains one or more type-length-value (TLV)-encoded options. + + + + + + + Defines the variable-length fields associated with IPv6 extension headers (the Hop-by-Hop Options header and the Destination Options header). Contains one or more type-length-value (TLV)-encoded options. + + + + + Identifies the type of option. This 8-bit Option Type identifier is internally encoded such that different bits have different meanings. These meanings are further specified in the IPv6OptionType type. + + + + + Length of the Option Data field of this option, in octets. + + + + + + + + + The Pad1 option is used to insert one octet of padding into the Options area of a header. The Pad1 option does not have length and value fields. + + + + + The PadN option is used to insert two or more octets of paddings into the Options area of a header. + + + + + + + + Specifies the fields of the Routing header, which is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination. http://tools.ietf.org/html/rfc2460 + + + + + Identifies the type of header immediately following the Routing header. Uses the same values as the IPv4 Protocol field. + + + + + length of the Routing header in 8-octet units, not including the first 8 octets. + + + + + 8-bit identifiers of a particular Routing header variant. Further definition will be added as required. + + + + + Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. http://tools.ietf.org/html/rfc2460 + + + + + Variable length field, of format determined by the Routing Type. + + + + + + + Specifies the fields of the Fragment header, which is used by an IPv6 source to send a packet larger than would fit in the path MTU. http://tools.ietf.org/html/rfc2460 + + + + + Each fragment has a header containing next header information, the offset of the fragment, an M flag specifying whether or not it is the last fragment, and an identification value. + + + + + The fragment of the packet that corresponds to the fragment header. The length of the fragment must fit with the MTU of the path to the packets' destination. + + + + + + + Defines fields for the IPv6 Destination Options header which is used to carry optional information that needs to be examined only by a packet's destination node(s). + + + + + Identifies the type of header immediately following the Destination_Options options header. Uses the same values as the IPv4 Protocol field. + + + + + Length of the Destination Options header in 8-octet units, not including the first 8 octets. + + + + + Variable-length field, of length such that the complete Destinations Options header is an integer multiple of 8 octets long. Contains one or more type-length-value (TLV)-encoded options. + + + + + + + The IP Authentication Header is used to provide connectionless integrity and data origin authentication for IP datagrams and to provide protection against replays. http://www.ietf.org/rfc/rfc2402.txt + + + + + Identifies the type of header immediately following the Authentication header. Uses the same values as the IPv4 Protocol field. + + + + + An 8-bit field specifying the length of the AH in 32-bit words. + + + + + The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), uniquely identifies the Security Association for this datagram. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use. http://www.ietf.org/rfc/rfc2402.txt + + + + + This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). + + + + + This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integer multiple of 32 bits in length. + + + + + + + ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. http://www.ietf.org/rfc/rfc2406.txt + + + + + The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the Security Association for this datagram. http://www.ietf.org/rfc/rfc2406.txt + + + + + This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). + + + + + Payload Data is a variable-length field containing data described by the Next Header field. + + + + + The padding field can be used for various reasons, such as to fill in the plaintext as required by an encryption algorithm or to conceal the actual length of the payload. + + + + + The pad length indicates the number of pad bytes immediately preceding it. Range is 0-255, where a value of zero indicates that no padding bytes are present. http://www.ietf.org/rfc/rfc2406.txt + + + + + Identifies the type data contained in the payload data field. Uses the same values as the IPv4 Protocol field. + + + + + The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. http://www.ietf.org/rfc/rfc2406.txt + + + + + + + The Pad1 type specifies how one octet of padding is inserted into the Options area of a header. The Pad1 option type does not have length and value fields. + + + + + The fixed 00 value specifies that the Pad1 option is used and also serves as the single octet of padding. + + + + + + + The PadN type specifies how two or more octets of padding are inserted into the Options area of a header. + + + + + Specifies the PandN option. + + + + + Length of the padding. For N octets of padding, the Option_Data_Length fields contains the value N-2. + + + + + Actual padding; consists of N-2 zero-valued octets. + + + + + + + Each fragment has a header containing next header information, the offset of the fragment, an M flag specifying whether or not it is the last fragment, and an identification value. + + + + + Identifies the type of header immediately following the Fragment header. Uses the same values as the IPv4 Protocol field. + + + + + 13-bit unsigned integer. The offset, in 8-octet units, of the data following this header, relative to the start of the Fragmentable Part or the original packet. + + + + + Indicates whether this is the last fragment or whether there are more fragments. + + + + + For every packet that is to be fragmented, the source node generates a 32-bit Identification value. + + + + + + + MFlagType specifies whether there are more fragments, via a union of the MFlagTypeEnum type and the atomic xs:string type. Its base type is the BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + Used by the IPv6 Fragment Header to indicate whether or not there are more fragments. + + + + + Fragment is the last fragment. + + + + + There are more fragments (current is not the last). + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Network_Route_Entry_Object.xsd b/stix_validator/schema/cybox/objects/Network_Route_Entry_Object.xsd new file mode 100755 index 0000000..8c9b596 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Network_Route_Entry_Object.xsd @@ -0,0 +1,155 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Network_Route_Entry_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Network_Route_Entry object is intended to characterize generic system network routing table entries. + + + + + The NetworkRouteEntryObjectType type is intended to characterize generic system network routing table entries. + + + + + + + The Destination_Address field specifies the destination IP address of the network route. It imports and uses the AddressObjectType from the CybOX Address object. + + + + + The Origin field specifies the origin address of the network route. It imports and uses the AddressObjectType from the CybOX Address object. + + + + + The Netmask field specifies the netmask for te destination network. + + + + + The Gateway_Address field specifies the IP address of the gateway through which all packets using this route will be gatewayed. It imports and uses the AddressObjectType from the CybOX Address object. + + + + + The Metric field specifies the distance to the target, in terms of hops. + + + + + The Type field specifies the type of network route being characterized. + + + + + The Protocol field specifies the name of the routing protocol that the route was added with. + + + + + The Interface field specifies the name of the network interface to which all packets for the route will be sent. + + + + + The Preferred_Lifetime field specifies the preferred lifetime of the route, in seconds. + + + + + The Valid_Lifetime field specifies the lifetime for which the route is valid, in seconds. + + + + + The Route_Age field specifies the number of seconds since the route was added or modified in the routing table. + + + + + + The is_ipv6 field specifies whether the route uses IPv6 addresses. + + + + + The is_autoconfigure_address field specifies whether the destination IP address for the route is automatically configured. + + + + + The is_immortal field specifies whether the lifetimes for the route prefixes are infinite. + + + + + The is_loopback field specifies whether the route is the default for all packets sent to local network addresses. + + + + + The is_publish field specifies whether the route is published. + + + + + + + + RouteType specifies route types, via a union of the RouteTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The RouteTypeEnum type is an enumeration of network route types. + + + + + + + + + + Indicates a route that is invalid. + + + + + Indicates routing from one machine directly to another, where both machines reside on the same physical network. + + + + + Indicates routing that is not direct and must be set to a gateway. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Network_Route_Object.xsd b/stix_validator/schema/cybox/objects/Network_Route_Object.xsd new file mode 100755 index 0000000..552103b --- /dev/null +++ b/stix_validator/schema/cybox/objects/Network_Route_Object.xsd @@ -0,0 +1,93 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Network_Route_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Network_Route_Object object is intended to specify a single network route. + + + + + The NetRouteObjectType type is intended to characterize a specific network route. + + + + + + + The Description field is intended for use in providing a brief description of the network route. + + + + + The Network_Route_Entries field is optional and characterizes a set of network route segment entries. + + + + + The Preferred_Lifetime field is intended to specify the preferred time, in seconds, that the IP route entry is valid. A value of 0xffffffff is considered to be infinite. + + + + + The Valid_Lifetime field is intended to specify the maximum time, in seconds, that the IP route entry is valid. A value of 0xffffffff is considered to be infinite. + + + + + The Route_Age field is intended to characterize the number of seconds since the route was added or modified in the network routing table. + + + + + + The is_ipv6 field specifies whether or not the route uses IPv6 addresses. + + + + + The is_autoconfigure_address field specifies if the IP address is autoconfigured. + + + + + The is_immortal field specifies if the route is immortal. + + + + + The is_loopback field specifies if the route is a loopback route (the gateway is on the local host). + + + + + The is_publish field specifies if the route is published. + + + + + + + + The NetworkRouteEntriesType type is intended to characterize the set of network route segments for this route. + + + + + The Network_Route field is optional and characterizes a single network route segment entry. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Network_Socket_Object.xsd b/stix_validator/schema/cybox/objects/Network_Socket_Object.xsd new file mode 100755 index 0000000..d3e1302 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Network_Socket_Object.xsd @@ -0,0 +1,524 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Network_Socket_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Network_Socket element is intended to characterize network sockets. + + + + + The NetworkSocketObjectType is intended to characterize network sockets. + + + + + + + The Address_Family field specifies the address family (AF_*) that the socket is configured for. + + + + + The Domain field specifies the communication domain (PF_*) of the socket. + + + + + The Local_Address field specifies the IP address and port for the socket on the local machine. + + + + + The Options field specifies any particular options used by the socket. + + + + + The Protocol field specifies the type of IP layer protocol used by the socket. + + + + + The Remote_Address field specifies the IP address and port for the socket on the remote machine. + + + + + The Type field specifies the type of socket being characterized. + + + + + + The is_blocking field specifies whether or not the socket is in blocking mode. + + + + + The is_listening field specifies whether or not the socket is in listening mode. + + + + + + + + The SocketOptionsType specifies any particular options used by the socket. If an options is supported only by specific address families or socket types, that's indicated in parentheses. + + + + + Set the interface over which outgoing multicast datagrams should be sent (AF_INET / SOCK_DGRAM or SOCK_RAW). + + + + + Set the interface over which outgoing multicast datagrams should be sent (AF_INET6 / SOCK_DGRAM or SOCK_RAW) . + + + + + Specify that the sending host receives a copy of an outgoing multicast datagram (AF_INET / SOCK_DGRAM or SOCK_RAW). + + + + + Set Type of Service (TOS) and Precedence in the IP header (AF_INET). + + + + + Enable the socket for issuing messages to a broadcast address (AF_INET / SOCK_DGRAM or SOCK_RAW). ( + + + + + Allows an application to decide whether or not to accept an incoming connection on a listening socket (Windows only). + + + + + Keep the connection up by sending periodic transmissions (AF_INET or AF_INET6 / SOCK_STREAM). + + + + + Bypass normal routing mechanisms (AF_INET or AF_INET6 ) + + + + + Specfies if the system attempts delivery of or discards any buffered data when a close() is issued. + + + + + Complement of SO_LINGER. + + + + + Indicates whether out-of-band data is received inline with normal data (AF_INET or AF_INET6). + + + + + Set size of the receive buffer. + + + + + Sets the relative priority for the socket in its group (Windows only). + + + + + Indicates if the local socket address can be reused (AF_INET or AF_INET6 / SOCK_DGRAM or SOCK_RAW) + + + + + Indicates if low-level debugging is active. + + + + + Set the receive timeout value. + + + + + Set size of the send buffer. + + + + + Set the send timeout value. + + + + + Updates the properties of the socket which are inherited from the listening socket (Windows only). + + + + + Set the socket timeout. + + + + + When set, TCP will send data immediately instead of using the Nagle delay algorithm (AF_INET or AF_INET6 / SOCK_STREAM). ( + + + + + + + AddressFamilyType specifies address family types, via a union of the AddressFamilyTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + DomainFamilyType specifies domain family types, via a union of the DomainTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + SocketType specifies socket types, via a union of the SocketTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + ProtocolType specifies protocol types, via a union of the ProtocolTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The AddressFamilyTypeEnum is an enumeration of address family (AF_*) types. + + + + + Specifies an unspecified address family. + + + + + Specifies sockets using for the Internet when using Berkeley sockets. + + + + + Specifies the IPX (Novell Internet Protocol) address family. + + + + + Specifies the APPLETALK DDP address family. + + + + + Specifies the NETBIOS address family. + + + + + Specifies the IP version 6 address family. + + + + + Specifies IRDA sockets. + + + + + Specifies BTH sockets. + + + + + + + The DomainTypeEnum is an enumeration of communication domain (PF_*) types. + + + + + Specifies the communication domain from local to host. + + + + + Specifies the communication domain from UNIX to host. + + + + + Specifies the communication domain from file to host. + + + + + Specifies the IP protocol family. + + + + + Specifies the Amateur Radio AX.25 family. + + + + + Specifies the Novell Internet Protocol family. + + + + + Specifies the IP version 6 protocol family. + + + + + Specifies the Appletalk DDP protocol family. + + + + + Specifies the Amateur radio NetROM protocol family. + + + + + Specifies the Multiprotocol bridge protocol family. + + + + + Specifies the ATM PVCs protocol family. + + + + + Specifies the protocol family reserved for the X.25 project. + + + + + Specifies the PF_KEY key management API family. + + + + + Specifies the protocol family reserved for the DECnet project. + + + + + Specifies the protocol family reserved for the 802.2LLC project. + + + + + Specifies the Security callback pseudo AF protocol family. + + + + + Specifies the PF_KEY key management API protocol family. + + + + + Specifies the netlink routing API family. + + + + + Specifies the PF_ROUTE routing API family. + + + + + Specifies the packet family. + + + + + Specifies the Ash family. + + + + + Specifies the Acorn Econet family. + + + + + Specifies the ATM SVCs protocol family. + + + + + Specifies the Linux SNA Project protocol family. + + + + + Specifies IRDA sockets. + + + + + Specifies PPPoX sockets. + + + + + Specifies Wanpipe API sockets. + + + + + Specifies Bluetooth sockets. + + + + + + + The SocketTypeEnum is an enumeration of socket (SOCK_*) types. + + + + + Specifies a pipe-like socket which operates over a connection with a particular remote socket, and transmits data reliably as a stream of bytes. + + + + + Specifies a socket in which individually-addressed packets are sent (datagram). + + + + + Specifies raw sockets which allow new IP protocls to be implemented in user space. A raw socket receives or sends the raw datagram not including link level headers. + + + + + Specifies a socket indicating a reliably-delivered message.. + + + + + Specifies a datagram congestion control Protocol socket. + + + + + + + The ProtocolTypeEnum is an enumeration of protocol types. + + + + + Indicates the ICMP protocol. + + + + + Indicates the IGMP protocol. + + + + + Indicates the Bluetooth protocol. + + + + + Indicates the TCP protocol. + + + + + Indicates the UDP protocol. + + + + + Indicates the ICMP v6 protocol. + + + + + Indicates the Reliable Multicating protocol. + + + + + diff --git a/stix_validator/schema/cybox/objects/Network_Subnet_Object.xsd b/stix_validator/schema/cybox/objects/Network_Subnet_Object.xsd new file mode 100755 index 0000000..7227543 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Network_Subnet_Object.xsd @@ -0,0 +1,64 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Network_Subnet_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + The Network_Subnet object is intended to characterize a generic system network subnet. + + + + + The NetworkSubnetObjectType type is intended to characterize a generic system network subnet. + + + + + + + The Name field is intended to specify a name for the network subnet. + + + + + The Description field is intended to provide a description of the network subnet. + + + + + The NumberOfIPAddresses field is intended to specify the number of valid IP addresses within the scope of the network subnet. + + + + + The Routes construct is intended to characterize a set of network routes. + + + + + + + + + The RoutesType is intended to characterize a set network routes. + + + + + The Route field is intended to characterize a single network route. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/PDF_File_Object.xsd b/stix_validator/schema/cybox/objects/PDF_File_Object.xsd new file mode 100755 index 0000000..8033820 --- /dev/null +++ b/stix_validator/schema/cybox/objects/PDF_File_Object.xsd @@ -0,0 +1,601 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + PDF_File_Object + 1.0 + 03/25/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. + All rights reserved. The contents of this file are subject to the terms of + the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See + the CybOX License for the specific language governing permissions and + limitations for use of this schema. When distributing copies of the CybOX + Schema, this license header must be included. + + + + + + + + The PDF_File element is intended to characterize the structural and metadata information regarding a single PDF file. + + + + + The PDFFileObjectType type is intended to characterize the structural makeup of PDF files. + + + + + + + The Metadata field captures some useful metadata associated with the PDF file. + + + + + The Version field specifies the decimal version number portion of the string from the PDF Header that specifies the version of the PDF specification to which the PDF file conforms, e.g. '1.4'. + + + + + The Indirect_Objects field captures the indirect objects included in the PDF file, representing the contents of a document. + + + + + The Cross_Reference_Tables field captures the cross-reference tables included in the PDF file, used for faciliting random access of indirect PDF objects. + + + + + The Trailers field captures the trailers included in the PDF file, used for capturing offsets to the cross-reference table and important objects. + + + + + + + + + The PDFXrefTableListType captures a list of PDF cross-reference tables. + + + + + The Cross_Reference_Table field captures the cross-reference table contained in the PDF file, for the random access of indirect objects contained in the file. + + + + + + + The PDFXRefTableType captures the details of a PDF cross-reference table, which provides a capability for the random access of indirect objects contained in the file. + + + + + The Subsections field captures the subsections contained in the cross-reference table. + + + + + The Offset field specifies the offset of the cross-reference from the beginning of the file, in bytes. + + + + + The Hashes field captures any hashes that were computed for the cross-reference table. + + + + + + + The PDFXrefTableSubsectionListType captures a list of cross-reference table subsections. + + + + + The Subsection field captures a single cross-reference table subsection in the list. + + + + + + + The PDFXrefTableSubsectionType captures details of subsections contained within a PDF cross-reference table. + + + + + The First_Object_Number field captures the object number of the first object for which there is a corresponding entry in this cross-reference subsection. + + + + + The Number_Of_Objects field captures the number of objects for which there are corresponding entries in this cross-reference subsection. + + + + + The Cross_Reference_Entries field specifies the cross-reference entries contained in this cross-reference subsection. + + + + + + + The PDFTrailerListType captures a list of PDF trailers. + + + + + The Trailer field captures a PDF file trailer contained in the file, used by applications for quickly locating the cross-reference table and certain special objects. + + + + + + + The PDFTrailerType captures the details of a PDF trailer. + + + + + The Size field captures the total number of entries in the file's cross-reference table. + + + + + The Prev field the byte offset from the beginning of the file to the beginning of the previous cross-reference table. This is only applicable for files that have more than one cross-reference table. + + + + + The Root field captures an indirect object reference that points to the catalog dictionary for the PDF document contained in the file. + + + + + The Encrypt field captures the PDF document's encryption dictionary, either through an indirect reference or embedded set of key/value pairs. + + + + + The Info field captures an indirect object reference that points to the document information dictionary. + + + + + The ID field captures an array of two strings that constitutes a file identifier. + + + + + The Last_Cross_Reference_Offset field captures the byte offset, relative to the beginning of the file, of the last cross-reference table contained in the file. + + + + + The Offset field specifies the offset of the trailer from the beginning of the file, in bytes. + + + + + The Hashes field captures any hashes that were computed for the trailer. + + + + + + + The PDFTrailerIDType captures the details of a PDF ID value stored in a trailer. + + + + + The ID_String field captures one of the two strings that constitutes the file identifier. + + + + + + + The PDFIndirectObjectListType captures a list of PDF indirect objects. + + + + + The Indirect_Object field captures a single PDF indirect object contained in the file. + + + + + + + The PDFObjectType captures the details of a PDF document indirect object, used in constructing and storing data associated with the PDF document. + + + + + The ID field specifies the identifier of the PDF indirect object, consisting of an object number and generation number. + + + + + The Contents field captures the contents of the PDF indirect object, including non-stream and stream data. + + + + + The Offset field specifies the offset of the PDF indirect object from the beginning of the file, in bytes. + + + + + The Hashes field captures any hashes that were computed for the PDF indirect object. + + + + + + The type field specifies the basic type of the PDF indirect object. + + + + + + The PDFIndirectObjectIDType captures the details of PDF indirect object IDs. + + + + + The Object_Number field captures the number portion of the indirect object ID. + + + + + The Generation_Number field captures the generation number portion of the indirect object ID. + + + + + + + The PDFIndirectObjectContentsType captures the contents of a PDF indirect object, including both stream and non-stream portions. + + + + + The Non_Stream_Contents field captures the raw contents of the PDF indirect object excluding any stream data (i.e. everything after the 'obj' keyword and before the 'endobj' keyword up to but not including anything between the 'stream' and 'endstream' keywords) as a string enclosed in an XML CDATA section. + + + + + The Stream_Contents field captures the stream contained within in the PDF indirect object, if applicable. + + + + + + + The PDFStreamType element captures details of PDF document stream objects, which represent arbitrary sequences of bytes. + + + + + The Raw_Stream element captures the raw, undecoded stream (i.e., everything between the 'stream' and 'endstream' keywords), as a hex string. + + + + + The Raw_Stream_Hashes field captures any hashes of the raw, undecoded stream. + + + + + The Decoded_Stream field captures the decoded stream (i.e., after undoing the specified filters in the correct order) as a hex string. + + + + + The Decoded_Stream_Hashes field captures any hashes of the decoded stream. + + + + + + + The PDFDocumentInformationDictionaryType captures details of the PDF Document Information Dictionary, used for storing metadata associated with the PDF document. + + + + + The Title field captures the title of the PDF document. + + + + + The Author field captures the name of the person who created the PDF document. + + + + + The Subject field captures the subject of the PDF document. + + + + + The Keywords field captures the keywords associated with the PDF document. + + + + + The Creator field captures the name of the application that created the original document, for cases where the original document was then converted to PDF. + + + + + The Producer field captures the name of the application that converted the document to PDF, for cases where the original document was then converted to PDF. + + + + + The CreationDate field captures the date and time that the document was created. + + + + + The ModDate field captures the date and time that the document was most recently modified. + + + + + The Trapped field captures a name object indicating whether the document has been modified to included trapping information. + + + + + + + The PDFXrefEntryListType captures a list of cross-reference table subsection entries. + + + + + The Cross_Reference_Entry field captures a single cross-reference subsection entry in the list. + + + + + + + The PDFXrefEntryType captures details of a cross-reference table subsection entry. + + + + + + The Byte_Offset field captures the 10-digit number, padded with leading zeros if necessary, that specifies the number of bytes from the beginning of the file to the beginning of the object. + + + + + The Object_Number field specifies the 10-digit object number of the next free object. + + + + + + The Generation_Number field specifies the 5-digit generation number to be used when an object with the same object number is created. + + + + + + The type field specifies the type of the cross-reference entry. + + + + + + The PDFDictionaryType captures a PDF dictionary as a set of key value pairs, or as a reference to an indirect object that contains. + + + + + The Object_Reference field captures a reference to an indirect PDF object that contains the dictionary, via its object and generation numbers. + + + + + The Raw_Contents field captures the contents of the dictionary as a string enclosed in an XML CDATA section. + + + + + + + The PDFFileMetadaType captures some metadata regarding the PDF file object. + + + + + The Document_Information_Dictionary field captures the details of the PDF Document Information Dicitonary, which includes properties like the document creation date and producer, if present in the PDF document. + + + + + The Number_Of_Indirect_Objects field captures the number of indirect PDF objects contained in the file. + + + + + The Number_Of_Trailers field captures the number of trailers contained in the file. + + + + + The Number_Of_Cross_Reference_Tables field captures the number of cross-reference tables contained in the file. + + + + + The Keyword_Counts field captures the counts of various PDF keyword names in the file. + + + + + + The encrypted field specifies whether the PDF file is encrypted. + + + + + The optimized field specifies whether the PDF file has been optimized. + + + + + + The PDFKeywordCountsType captures the occurrences of various keywords in a PDF file. + + + + + The Page_Count field captures the number of occurrences of the '/Page' keyword in the PDF file, which provides an indication of the number of pages in the PDF document. + + + + + The Encrypt_Count field captures the number of occurrences of the '/Encrypt' keyword in the PDF file, which indicates that the PDF uses encryption. + + + + + The ObjStm_Count field captures the number of occurrences of the '/ObjStm' keyword in the PDF file. + + + + + The JS_Count field captures the number of occurrences of the '/JS' keyword in the PDF file. + + + + + The JavaScript_Count field captures the number of occurrences of the '/JavaScript' keyword in the PDF file. + + + + + The AA_Count field captures the number of occurrences of the '/AA' keyword in the PDF file. + + + + + The OpenAction_Count field captures the number of occurrences of the '/OpenAction' keyword in the PDF file. + + + + + The ASCIIHexDecode_Count field captures the number of occurrences of the '/ASCIIHexDecode' keyword in the PDF file. + + + + + The ASCII85Decode_Count field captures the number of occurrences of the '/ASCII85Decode' keyword in the PDF file. + + + + + The LZWDecode_Count field captures the number of occurrences of the '/LZWDecode' keyword in the PDF file. + + + + + The FlateDecode_Count field captures the number of occurrences of the '/FlateDecode' keyword in the PDF file. + + + + + The RunLengthDecode_Count field captures the number of occurrences of the '/RunLengthDecode' keyword in the PDF file. + + + + + The JBIG2Decode_Count field captures the number of occurrences of the '/JBIG2Decode' keyword in the PDF file. + + + + + The DCTDecode_Count field captures the number of occurrences of the '/DCTDecode' keyword in the PDF file. + + + + + The RichMedia_Count field captures the number of occurrences of the '/RichMedia' keyword in the PDF file. + + + + + The CCITTFaxDecode_Count field captures the number of occurrences of the '/CCITTFaxDecode' keyword in the PDF file. + + + + + The Launch_Count field captures the number of occurrences of the '/Launch' keyword in the PDF file. + + + + + The XFA_Count field captures the number of occurrences of the '/XFA' keyword in the PDF file. + + + + + + + The PDFKeywordCountType captures the obfuscated and non-obfuscated occurrences of a keyword. + + + + + The Non_Obfuscated_Count field captures the number of times the keyword occurred in the PDF file without any obfuscation. + + + + + The Obfuscated_Count field captures the number of times the keyword occurred in the PDF file with some form of obfuscation, such as with hexcodes. + + + + + + + The PDFObjectTypeEnum is an enumeration of basic PDF document object types. + + + + + + + + + + + + + + + The PDFXrefEntryTypeEnum is an enumeration of PDF cross-reference table entry types. + + + + + + + diff --git a/stix_validator/schema/cybox/objects/Pipe_Object.xsd b/stix_validator/schema/cybox/objects/Pipe_Object.xsd new file mode 100755 index 0000000..a9e7c64 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Pipe_Object.xsd @@ -0,0 +1,40 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Pipe_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Pipe object is intended to characterize generic system pipes. + + + + + The PipeObjectType type is intended to characterize generic system pipes. + + + + + + + The Name field specifies the name of the pipe, if applicable. + + + + + + The named field specifies whether the pipe is named. + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Port_Object.xsd b/stix_validator/schema/cybox/objects/Port_Object.xsd new file mode 100755 index 0000000..51cf86f --- /dev/null +++ b/stix_validator/schema/cybox/objects/Port_Object.xsd @@ -0,0 +1,74 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Port_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Port object is intended to characterize networking ports. + + + + + The PortObjectType type is intended to characterize networking ports. + + + + + + + The required Port_Value field specifies the actual value of the port. + + + + + The Layer4_Protocol field specifies the Layer 4 Protocol (OSI Model) associated with the port. + + + + + + + + + Layer4ProtocolType specifies Layer 4 (OSI model) protocols, via a union of the Layer4ProtocolEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The Layer4ProtocolEnum type is an enumeration of relevant Layer4 networking protocols. + + + + + Indicates the Layer 4 (OSI model) TCP protocol. + + + + + Indicates the Layer 4 (OSI model) UDP protocol. + + + + + diff --git a/stix_validator/schema/cybox/objects/Process_Object.xsd b/stix_validator/schema/cybox/objects/Process_Object.xsd new file mode 100755 index 0000000..7fa23d6 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Process_Object.xsd @@ -0,0 +1,197 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Process_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + The Process object is intended to characterize system processes. + + + + + The ProcessObjectType type is intended to characterize system processes. + + + + + + + The PID field specifies the Process ID, or PID, of the process. + + + + + The Name field specifies the name of the process. + + + + + The Creation_Time field specifies the local date/time at which the process was created. + + + + + The Parent_PID field specifies the process ID (PID) of the parent process (i.e. the process that spawned this one), if applicable. + + + + + The Child_PID_List field specifies any children spawned by the process being characterized, by way of a list of PIDs. + + + + + The Image_Info field specifies information about the image associated with the process, such as its file name and path. + + + + + The Argument_List field is optional and specifies a list of arguments utlized in intiating the process. + + + + + The Environment_Variable_List field specifies any environment variables associated with the process. This field imports and uses the EnvironmentVariableListType from the CybOX Common Types. + + + + + The Kernel_Time field specifies the duration of time that the process has executed in kernel mode. + + + + + The Port_List field is optional and specifies a list of ports owned by the process. + + + + + The Network_Connection_List field specifies information about any network connections opened or initiated by the process. + + + + + The Start_Time field specifies the local date/time at which the process was started. + + + + + The Status field specifies the current status of the process. Since this is an operating system specific Object property, this is defined here as an abstract type which is then used as a base type in any OS-specific extensions. + + + + + The Username field specifies the name of the user that created the process. + + + + + The User_Time field specifies the duration of time that the process has executed in user mode. + + + + + A description of features extracted from the memory image of this process. + + + + + + The is_hidden field specifies whether the process is hidden or not. + + + + + + + + The NetworkConnectionListType type is a list of network connections. + + + + + The Network_Connection field specifies information about a single network connection opened or initiated by the process. + + + + + + + The ImageInfoType type captures information about the process image. + + + + + The File_Name field specifies the name of the binary file which represents the process image. + + + + + The Command_Line field specifies the complete command used to execute the process image. + + + + + The Current_Directory field specifies the current directory of the process image. + + + + + The Path field specifies the fully qualified path to the image file, including the file name. + + + + + + + The ProcessStatusType is used for specifying the status of a running or terminated process. Since this property is platform-specific, it is created here as an abstract type and then used in the platform-specific process CybOX objects. + + + + + The ChildPIDListType type captures the PID's of the children of the process in a list format. + + + + + The Child_PID field specifies the process ID of a single child process. + + + + + + + The ArgumentListType is intended to specify a list of arguments utlized in intiating the process. + + + + + The Argument field is optional and specifies a single argument utlized in intiating the process. + + + + + + + The PortListType is intended to specify a list of network ports. + + + + + The Port field is optional and specifies a single network port. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Product_Object.xsd b/stix_validator/schema/cybox/objects/Product_Object.xsd new file mode 100755 index 0000000..30c910d --- /dev/null +++ b/stix_validator/schema/cybox/objects/Product_Object.xsd @@ -0,0 +1,60 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Product_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Product object is intended to characterize software or hardware products. + + + + + The ProductObjectType type is intended to characterize software or hardware products. + + + + + + + The Edition field specifies the edition of the product, if applicable. + + + + + The Language field specifies the language of the product, if applicable. + + + + + The Product field specifies the name of the product. This field is required. + + + + + The Update field specifies the update/revision of the product, if applicable. + + + + + The Vendor field specifies the name of the product vendor. This field is required. + + + + + The Version field speciifes the version of the product, if applicable. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Semaphore_Object.xsd b/stix_validator/schema/cybox/objects/Semaphore_Object.xsd new file mode 100755 index 0000000..7b0c087 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Semaphore_Object.xsd @@ -0,0 +1,50 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Semaphore_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Semaphore object is intended to characterize generic semaphore objects. + + + + + The SemaphoreObjectType type is intended to characterize generic semaphore objects. + + + + + + + The Current_Count field specifies the current count value for the semaphore. + + + + + The Maximum_Count field specifies the maximum count value for the semaphore. + + + + + The Name field specifies the name of the semaphore, if applicable. + + + + + + The named field specifies whether the Semaphore is named. + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Socket_Address_Object.xsd b/stix_validator/schema/cybox/objects/Socket_Address_Object.xsd new file mode 100755 index 0000000..d77cf07 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Socket_Address_Object.xsd @@ -0,0 +1,42 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Socket_Address_Object + 2.0 + 03/27/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + The Socket_Address element is intended to characterize a single socket address. + + + + + The SocketAddressObjectType specifies an IP address/port number pair. + + + + + + + The IP_Address field specifies the IP address component of the socket address. + + + + + The Port field specifies the port number component of the socket connection. + + + + + + + diff --git a/stix_validator/schema/cybox/objects/System_Object.xsd b/stix_validator/schema/cybox/objects/System_Object.xsd new file mode 100755 index 0000000..d8f61d3 --- /dev/null +++ b/stix_validator/schema/cybox/objects/System_Object.xsd @@ -0,0 +1,409 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + System_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The System object is intended to characterize computer systems (as a combination of both software and hardware). + + + + + The SystemObjectType type is intended to characterize computer systems (as a combination of both software and hardware). + + + + + + + The Available_Physical_Memory field specifies the amount of physical memory available on the system, in bytes. + + + + + The BIOS_Info field specifies information about the BIOS on the system. + + + + + The Date field specifies the current date on the system. + + + + + The Hostname field specifies the hostname of the system. + + + + + The Local_Time field specifies the local time on the system. + + + + + The Network_Interface_List field specifies the list of network interfaces present on the system. + + + + + The OS field specifies information about the operating system installed on the system. + + + + + The Processor field specifies the name of the CPU used by the system. + + + + + The Processor_Architecture field specifies the specific architecture (e.g. x86) used by the CPU of the system. + + + + + The System_Time field specifies the system, or hardware, time on the system. + + + + + The Timezone_DST field specifies the time zone used by the system, taking daylight savings time (DST) into account. + + + + + The Timezone_Standard field specifies the time zone used by the system, wihtout taking daylight savings time (DST) into account. + + + + + The Total_Physical_Memory field specifies the total amount of physical memory present on the system, in bytes. + + + + + The Uptime field specifies the duration that represents the current amount of time that the system has been up. + + + + + The Username field specifies the name of the user currently logged into the system. + + + + + + + + + The BIOSInfoType type specifies information about a system's BIOS. + + + + + The BIOS_Date field specifies the date of the bios (e.g. the datestamp of the BIOS revision). + + + + + The BIOS_Version field specifies the version of the BIOS. + + + + + The BIOS_Manufacturer field specifies the manufacturer of the BIOS. + + + + + The BIOS_Release_Date field specifies the date the BIOS was released. + + + + + The BIOS_Serial_Number field specifies the serial number of the BIOS. + + + + + + + The NetworkInterfaceListType type specifies information about the network interfaces present on the system. + + + + + The Network_Interface field specifies information about a network interface, such as its MAC address. + + + + + + + The IPGatewayListType type specifies the IP Addresses of the gateways used by the system. + + + + + The IP_Gateway_Address field specifies the IP Address of a gateway used by the system. + + + + + + + The NetworkInterfaceType type specifies information about a network interface, such as its MAC address. + + + + + The Adapter field specifies the name of the network adapter used by the network interface. + + + + + The Description field specifies the description of the network interface. + + + + + The DHCP_Lease_Expires field specifies the date/time that the DHCP lease obtained on the network interface expires. + + + + + The DHCP_Lease_Obtained field specifies the date/time that the DHCP lease was obtained on the network interface. + + + + + The DHCP_Server_List field specifies the list of DHCP servers used by the network interface. + + + + + The IP_Gateway_List field specifies the list of IP Gateways used by the network interface. + + + + + The IP_List field specifies the list of IP addresses used by the network interface. + + + + + The MAC field specifies the MAC or hardware address of the physical network card. Either a colon (':') or a dash ('-') may be used a separator between the octets. + + + + + + + The IPInfoListType type specifies a list of IP address/subnet mask pairs associated with a network interface. + + + + + The IP_Info field specifies an IP Address/Subnet mask entry in the list. + + + + + + + The IP_Info type specifies information about the IP address and its associated subnet mask used by a network interface. + + + + + The IP_Address field specifies an IP address. + + + + + The Subnet_Mask field specifies a subnet mask. + + + + + + + The DHCPServerListType type specifies a list of DHCP Servers, via their IP addresses. + + + + + The DHCP_Server_Address field specifies the IP address of a DHCP server. + + + + + + + The OSType type specifies information about an operating system. It imports and extends the PlatformSpecificationType from the CybOX Common Types. + + + + + + + The Bitness field specifies the bitness of the operating system (i.e. 32 or 64). + + + + + The Build_Number field specifies the build number of the operating system. + + + + + The EnvironmentVariableList field specifies a list of environment variables present on the operating system. + + + + + The Install_Date field specifies the date the operating system was installed. + + + + + The Patch_Level field specifies the patch level of the operating system. + + + + + This field contains general identifiers for this OS instance.. + + + + + + + + + ProcessorArchType specifies CPU architecture types, via a union of the ProcessorArchEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + BitnessType specifies CPU architecture bitness, via a union of the BitnessEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The ProcessorArchEnum type is a (non-exhaustive) enumeration of computer processor architectures. + + + + + Specifies the 32-bit x86 architecture. + + + + + Specifies the 64-bit x86 architecture. + + + + + Specifies the 64-bit IA (Itanium) architecture. + + + + + Specifies the PowerPC IA (Itanium) architecture. + + + + + Specifies the ARM architecture. + + + + + Specifies the Alpha architecture. + + + + + Specifies the SPARC architecture. + + + + + Specifies the z/architecture, used on IBM mainframes. + + + + + Specifies the eSi-RISC architecture. + + + + + Specifies the MIPS architecture. + + + + + Specifies the Motorola 68k architecture. + + + + + Specifies a processor architecture other than those defined in this enumeration. + + + + + + + The BitnessEnum type is an enumeration of word sizes that define classes of computer architectures. + + + + + Specifies a 32-bit architecture. + + + + + Specifies a 64-bit architecture. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/URI_Object.xsd b/stix_validator/schema/cybox/objects/URI_Object.xsd new file mode 100755 index 0000000..7329268 --- /dev/null +++ b/stix_validator/schema/cybox/objects/URI_Object.xsd @@ -0,0 +1,62 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + URI_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The URI object is intended to characterize Uniform Resource Identifiers (URI's). + + + + + The URIObjectType type is intended to characterize Uniform Resource Identifiers (URI's). + + + + + + + The Value field specifies the value of the URI. + + + + + + The type field specifies the type of URI that is being defined. + + + + + + + + The URITypeEnum is an enumeration of types of URIs. + + + + + Specifies a URL type of URI. + + + + + Specifies a General URN type of URI. + + + + + Specifies a Domain Name type of URI. + + + + + diff --git a/stix_validator/schema/cybox/objects/Unix_File_Object.xsd b/stix_validator/schema/cybox/objects/Unix_File_Object.xsd new file mode 100755 index 0000000..b7612a2 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Unix_File_Object.xsd @@ -0,0 +1,164 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Unix_File_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Unix_File object is intended to characterize Unix files. + + + + + The UnixFileObjectType type is intended to characterize Unix files. + + + + + + + The Group_Owner field specifies the name of the group which owns the file. + + + + + The INode field specifies the inode, or index node, value of the file. + + + + + Specifies file type using the UnixFileTypeEnum enumeration. + + + + + + + + + The UnixFilePermissionsType type specifies the specific permissions used by the Unix family of operating systems. + + + + + + The suid field specifies whether or not the file may be exectued with the privileges of the file's owner. + + + + + The sgid field specifies whether or not the file may be executed with the privileges of the file's group owner. + + + + + The uread field specifies whether or not the owner of the file can read its contents. + + + + + The uwrite field specifies whether or not the owner of the file can write to it. + + + + + The uexec field specifies whether or not the owner of the file can execute it. + + + + + The gread field specifies whether or not the group owner of the file can read its contents. + + + + + The gwrite field specifies whether or not the group owner of the file can write to it. + + + + + The gexec field specifies whether or not the group owner of the file can execute it. + + + + + The oread field specifies whether or not all other users can read the contents of the file. + + + + + The owrite field specifies whether or not all other users can write to the file. + + + + + The oexec field specifies whether or not all other users can execute the file. + + + + + + + + UnixFileType specifies Unix file types, via a union of the UnixFileTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The UnixFileTypeEnum type is an enumeration of file types used by the Unix family of operating systems. These file types can be determined via the output of the ls and stat commands. + + + + + Specifies a regular file, denoted in UNIX by the first dash (-) in a file with permissions -rw-r--r--. + + + + + Specifies a directory, denoted in UNIX by the d in a file with permissions drw-r--r--. + + + + + Specifies a socket, denoted in UNIX by the s in a file with permissions srw-r--r--. + + + + + Specifies a symbolic link, denoted in UNIX by the l in a file with permissions lrw-r--r--. + + + + + Specifies a block device, such as /dev/sda, denoted in UNIX by the b in a file with permissions brw-rw----. + + + + + Specifies a character device, such as /dev/null, denoted in UNIX by the c in a file with permissions crw-------. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Unix_Network_Route_Entry_Object.xsd b/stix_validator/schema/cybox/objects/Unix_Network_Route_Entry_Object.xsd new file mode 100755 index 0000000..1e97a6c --- /dev/null +++ b/stix_validator/schema/cybox/objects/Unix_Network_Route_Entry_Object.xsd @@ -0,0 +1,56 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Unix_Network_Route_Entry_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Unix_Network_Route_Entry object is intended to characterize entries in the network routing table of a Unix system. + + + + + The UnixNetworkRouteEntryObjectType type is intended to characterize entries in the network routing table of a Unix system. + + + + + + + The Flags field specifies any flags used for the network route, such as G (use gateway). + + + + + The MSS field specifies the maximum segment size for TCP connections over this network route, in bytes. + + + + + The Ref field specifies the number of references to this network route. + + + + + The Use field specifies the number of lookups that were performed for this network route. + + + + + The Window field specifies the default window size for TCP connections over this network route, in bytes. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Unix_Pipe_Object.xsd b/stix_validator/schema/cybox/objects/Unix_Pipe_Object.xsd new file mode 100755 index 0000000..72c8e8f --- /dev/null +++ b/stix_validator/schema/cybox/objects/Unix_Pipe_Object.xsd @@ -0,0 +1,36 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Unix_Pipe_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Unix_Pipe object is intended to characterize Unix pipes. + + + + + The UnixPipeObjectType type is intended to characterize Unix pipes. + + + + + + + The Permission_Mode field specifies the Unix permission mode for the pipe. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Unix_Process_Object.xsd b/stix_validator/schema/cybox/objects/Unix_Process_Object.xsd new file mode 100755 index 0000000..70b2649 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Unix_Process_Object.xsd @@ -0,0 +1,143 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Unix_Process_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Unix_Process object is intended to characterize Unix processes. + + + + + The UnixProcessObjectType type is intended to characterize Unix processes. + + + + + + + The Open_File_Descriptor_List field specifies a listing of the current file descriptors used by the Unix process. + + + + + The Priority field specifies the priority of the Unix process. + + + + + The RUID field specifies the real user ID, which represents the Unix user who created the process. + + + + + The Session_ID field specifies the Unix Sesssion ID of the process. + + + + + + + + + The UnixProcessStatusType field specifies the current status of the running Unix process. It extends the abstract ProcessStatusType from the CybOX Process Object. + + + + + + + Specifies the current state of the Unix process, using the UnixProcessStatusEnum enumeration. + + + + + Specifies when the process started up. + + + + + + + + + The FileDescriptorListType type specifies a list of Unix file descriptors. + + + + + The File_Descriptor field specifies a particular Unix File Descriptor. + + + + + + + UnixProcessStateType specifies Unix process states, via a union of the UnixProcessStateEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. See "man ps" for more information. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The UnixProcessStateEnum is an enumeration of Unix process states. + + + + + Specifies a running process or runnable [on run queue] (R). + + + + + Specifies a process in uninterruptable sleep [usually IO] (D). + + + + + Specifies a process in interruptable sleep [waiting for an event to complete] (S). + + + + + Specifies a stopped process, either by a job control signal or because it is being traced (T). + + + + + Specifies a paging process [not valid since the 2.6.xx kernel] (W). + + + + + Specifies a dead process [should never be seen] (X). + + + + + Specifies a defunct, zombie process [terminated but not reaped by its parent] (Z). + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Unix_User_Account_Object.xsd b/stix_validator/schema/cybox/objects/Unix_User_Account_Object.xsd new file mode 100755 index 0000000..d955888 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Unix_User_Account_Object.xsd @@ -0,0 +1,78 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Unix_User_Account_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Unix_User_Account object is intended to characterize Unix user account objects. + + + + + The UnixUserAccountType type is intended to characterize Unix user accounts. + + + + + + + The Group_ID field specifies the ID of the primary group to which the Unix user account belongs. + + + + + The User_ID field specifies the ID of the Unix user account. + + + + + The Login_Shell field specifies the name of the default login shell used by the Unix user account. + + + + + + + + + The UnixGroupType type is used for specifying Unix groups. It extends the abstract GroupType from the Cybox UserAccount construct. + + + + + + + The Group_ID field specifies the Unix ID of the group. + + + + + + + + + The UnixPrivilegeType type is used to specify Unix privileges. It extends the abstract PrivilegeType from the CybOX UserAccount object. + + + + + + + The Permissions_Mask field specifies the Unix permissions mask for the privilege. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Unix_Volume_Object.xsd b/stix_validator/schema/cybox/objects/Unix_Volume_Object.xsd new file mode 100755 index 0000000..fd5b4d0 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Unix_Volume_Object.xsd @@ -0,0 +1,41 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Unix_Volume_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Unix_Volume object is intended to characterize Unix disk volumes. + + + + + The UnixVolumeObjectType type is intended to characterize Unix disk volumes. + + + + + + + The Mount_Point field specifies the specific mounting point for the Unix volume. + + + + + The Options field specifies any options used when mounting the volume. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/User_Account_Object.xsd b/stix_validator/schema/cybox/objects/User_Account_Object.xsd new file mode 100755 index 0000000..43486f1 --- /dev/null +++ b/stix_validator/schema/cybox/objects/User_Account_Object.xsd @@ -0,0 +1,110 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + User_Account_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The User_Account object is intended to characterize generic user accounts. + + + + + The UserAccountObjectType type is intended to characterize generic user accounts. + + + + + + + The Full_Name field specifies the full name of the user for which this account was created. + + + + + The Group_List field specifies the list of groups to which the user account belongs to. + + + + + The Home_Directory field specifies the fully-qualified path to the home directory of the user account. + + + + + The Last_Login field specifies the date/time that the user account was last logged into. + + + + + The Privilege_List field specifies the privileges that the user account has. + + + + + The Script_Path field specifies the fully-qualified path to the directory where the logon script for the user account resides. + + + + + The Username field specifies the particular username of the user account. + + + + + The User_Password_Age field specifies the current age of the user account's password. + + + + + + The password_required field specifies whether a password is required for this user account. + + + + + + + + The PrivilegeListType type specifies the list of privileges that the user account has. + + + + + The Privilege field specifies a specific privilege that a user has. This is an abstract type since user privileges are operating-system specific, and is extended as needed in the derived CybOX object schemas. + + + + + + + The PrivilegeType type specifies a specific privilege that a user has. This is an abstract type since user privileges are operating-system specific, and is extended as needed in the derived CybOX object schemas. + + + + + The GroupListType type specifies the groups that the user account belongs to. + + + + + The Group field specifies a group that a user account belongs to. This is an abstract type since group IDs are operating-system specific, and is extended as needed in the derived CybOX object schemas. + + + + + + + The GroupType type specifies a group that a user account belongs to. This is an abstract type since group IDs are operating-system specific, and is extended as needed in the derived CybOX object schemas. + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/User_Session_Object.xsd b/stix_validator/schema/cybox/objects/User_Session_Object.xsd new file mode 100755 index 0000000..b848d6b --- /dev/null +++ b/stix_validator/schema/cybox/objects/User_Session_Object.xsd @@ -0,0 +1,60 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + User_Session_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The User_Session object is intended to characterize user sessions. + + + + + The UserSessionObjectType type is intended to characterize user sessions. + + + + + + + The Effective_Group field specifies the name of the effective group used in the user session. + + + + + The Effective_Group_ID field specifies the effective group ID of the group used in the user session. + + + + + The Effective_User field specifies the effective username used in the user session. + + + + + The Effective_Group field specifies the effective user ID of the user used in the user session. + + + + + The Login_Time field specifies the date/time of the login for the user session. + + + + + The Logout_Time field specifies the date/time of the logout for the user session. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Volume_Object.xsd b/stix_validator/schema/cybox/objects/Volume_Object.xsd new file mode 100755 index 0000000..8caf9c0 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Volume_Object.xsd @@ -0,0 +1,235 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Volume_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Volume object is intended to characterize generic drive volumes. + + + + + The VolumeObjectType type is intended to characterize generic drive volumes. + + + + + + + The Name field specifies the name of the volume. + + + + + The Device_Path specifies the full path to the volume, including the device on which it resides. + + + + + The File_System_Type field specifies the name of the file system which is used on the volume. + + + + + The Total_Allocation_Units field specifies the total number of allocation units available on the volume. + + + + + The Sectors_Per_Allocation_Unit field speciifes the number of disk sectors used for each allocation unit on the volume. + + + + + The Bytes_Per_Sector field specifies the number of bytes allocated for each sector of the volume. + + + + + The Actual_Available_Allocation_Units field specifies the number of allocation units, or clusters, available on the volume. + + + + + The Creation_Time field specifies the date/time that the volume was created. + + + + + The File_System_Flag_List field specifies the particular flags set for the volume by the file system which is used on the volume. + + + + + The Serial_Number field specifies the serial number of the volume. + + + + + + The is_mounted field specifies whether the volume is mounted. + + + + + + + + The VolumeOptionsType type specifies the particular options set for the volume. This is an abstract type since volume options are OS-specific, and is extended by the related OS-specific CybOX volume objects. + + + + + The FileSystemFlagListType is a listing of the flags specified for the volume by the file system. + + + + + The File_System_Flag field specifies a particular flag used on the volume by the file system. + + + + + + + VolumeFileSystemFlagType specifies file system flags, via a union of the VolumeFileSystemFlagEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The FileSystemFlagEnum type is an enumeration of flags used by file systems on volumes, especially those on Windows Operating Systems. See http://msdn.microsoft.com/en-us/library/windows/desktop/aa364993(v=vs.85).aspx and http://msdn.microsoft.com/en-us/library/cc232101(v=prot.13).aspx for more information. + + + + + + + Indicates that the specified volume supports case-sensitive file names. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00000001. + + + + + Indicates that the specified volume supports preserved case of file names when it places a name on disk. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00000002. + + + + + Indicates that the specified volume supports preserved case of file names when it places a name on disk. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00000004. + + + + + Indicates that the specified volume preserves and enforces access control lists (ACL). For example, the NTFS file system preserves and enforces ACLs, and the FAT file system does not. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00000008. + + + + + Indicates that the specified volume supports file-based compression. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00000010. + + + + + Indicates that the specified volume supports disk quotas. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00000020. + + + + + Indicates that the specified volume supports sparse files. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00000040. + + + + + Indicates that the specified volume supports re-parse points. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00000080. + + + + + Indicates that the specified volume supports remote storage. This is not listed with a lpFileSystemFlags value in documentation, but corresponds to the FileSystemAttributes value 0x00000100. + + + + + Indicates that the specified volume is a compressed volume, for example, a DoubleSpace volume. This flag is incompatible with the FILE_FILE_COMPRESSION flag. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00008000. + + + + + Indicates that the specified volume supports object identifiers. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00010000. + + + + + Indicates that the specified volume supports encryption. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00020000. + + + + + Indicates that the specified volume supports named streams. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00040000. + + + + + Indicates that the specified volume is read-only. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00080000. + + + + + Indicates that the specified volume supports a single sequential write. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00100000. + + + + + Indicates that the specified volume supports transactions. For more information about transactions, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa365993(v=vs.85).aspx. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00200000. + + + + + Indicates that the specified volume supports hard links. For more information about hard links, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa365006(v=vs.85).aspx. Note that hard links are DIFFERENT from symbolic links. This value is ONLY supported for Windows Server 2008 R2 and Windows 7 and later. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00400000. + + + + + Indicates that the specified volume supports extended attributes. An extended attribute is a piece of application-specific metadata that an application can associate with a file and is not part of the file's data. This value is ONLY supported for Windows Server 2008 R2 and Windows 7 and later. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x00800000. + + + + + Indicates that the specified volume supports open by FileID. For more information about open by FileID, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa364226(v=vs.85).aspx. This value is ONLY supported for Windows Server 2008 R2 and Windows 7 and later. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x01000000. + + + + + Indicates that the specified volume supports unique service number (USN) journals. For more information about USN journals, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa363803(v=vs.85).aspx. This value is ONLY supported for Windows Server 2008 R2 and Windows 7 and later. This corresponds to the lpFileSystemFlags and FileSystemAttributes value 0x02000000. + + + + + Indicates that the specified volume supports integrity streams. Currently, this value is ONLY available for ReFS and Windows 8 Beta. This corresponds to the FileSystemAttributes value 0x04000000. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Whois_Object.xsd b/stix_validator/schema/cybox/objects/Whois_Object.xsd new file mode 100755 index 0000000..a004111 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Whois_Object.xsd @@ -0,0 +1,456 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Whois_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + The Whois_Entry object is intended to characterize an individual Whois entry for a domain. + + + + + The WhoisObjectType type is intended to characterize Whois information for a domain. + + + + + + + The Domain_Name field specifies the corresponding domain name for this whois entry + + + + + The Domain_ID field specifies the domain id for the domain associated with this Whois entry + + + + + The Server_Name field specifies the corresponding server name for this whois entry. This usually corresponds to a nameserver lookup. + + + + + The IP_Address field specifies the corresponding ip address for this whois entry. The usually corresponds to a nameserver lookup. + + + + + The DNSSEC element corresponds to the DNSSEC field associated with a Whois entry. Acceptable values are: "Signed" or "Unsigned". + + + + + The Nameservers element represents a list of nameserver entries for a Whois entry. + + + + + The Status element represents a list of statuses for a given Whois entry. + + + + + The Updated_Date field specifies the date in which the registered domain information was last updated + + + + + The Creation_Date field specifies the date in which the registered domain was created + + + + + The Expiration_Date field specifies the date in which the registered domain will expire + + + + + The Regional_Internet_Registry field specifies the name of the Regional Internet Registry (RIR) which allocated the IP address contained in this WHOIS entry. + + + + + The Sponsoring_Registrar field holds the name of the sponsoring registrar for the domain + + + + + The Registrar_Info element represents registrar info that would be returned from a registrar lookup + + + + + The Registrants element represents the registrant information associated with a domain lookup + + + + + The Contact_Info element represents contact info that would be returned from a contact lookup + + + + + + + + + + The WhoisStatusEnum enumeration lists all valid statuses for a domain within a whois entry + + + + + The 5-day Add Grace Period after the initial registration of a domain. If the domain is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the registration. + + + + + The 5-day period after a domain registration period is explicitly extended (renewed) by the registrar. If the domain is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal. + + + + + The 45-day period after a domain registration period expires and is extended (renewed) automatically by the registry. If the domain is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal. + + + + + The 5-day period after the successful transfer of domain name registration sponsorship from one registrar to another registrar. If the domain is deleted by the new sponsoring registrar during this period, the registry provides a credit to the registrar for the cost of the transfer. + + + + + The 30-day period after a registrar has submitted a delete command to delete a domain from the registry. All Internet services associated with the domain are disabled. During this period, a registrar can submit a request to Restore the domain. + + + + + The 5-day period following the PENDING DELETE RESTORABLE period. During this period, all Internet services associated with the domain will remain disabled and domain cannot be Restored. + + + + + The registrar has submitted a Restore request for a domain that was previously in the status of PENDING DELETE RESTORABLE and the registry is awaiting a Restore Report from the registrar. + + + + + This is the normal status for a domain that has no pending operations or prohibitions. + + + + + The domain has no associated nameservers. A minimum of 2 nameservers must be associated with the domain before it can be published to the zone. + + + + + Registrar does not allow the transfer of a domain. + + + + + Registrar does not allow the renewal of a domain. + + + + + Registrar does not allow the deletion of a domain. + + + + + Registrar does not allow the update or modification of a domain. + + + + + Registrar will not allow the domain to be published to the zone. + + + + + Registry does not allow the transfer of a domain. + + + + + Registry does not allow the renewal of a domain. + + + + + Registry does not allow the deletion of a domain. + + + + + Registry does not allow all the update or modification of a domain. + + + + + Registry will not allow the domain to be published to the zone. + + + + + + + + + + The Registrar_ID corresponds to the Registrar ID field of a Whois entry + + + + + The Registrar_GUID corresponds to the Registrar GUID field of a Whois entry + + + + + The Name field holds the name of the registrar organization + + + + + The Address field holds the address (location) of the registrar organization + + + + + The main email address for the registrar + + + + + The Phone_Number field holds the phone number of the registrar organization + + + + + The Whois_Server field specifies the corresponding whois server for this registrar + + + + + The Referral_URL field specifies the corresponding referral URL for registrar + + + + + A list of registrar contacts + + + + + + + + The WhoisDNSSECTypeEnum defines an enumeration of acceptable values for the DNSSEC field in a Whois entry + + + + + The Signed value signifies that the domain name associated with the Whois entry is digitally signed + + + + + The Unsigned value signfies that the domain name associated with the Whois entry is not digitally signed + + + + + + + + The WhoisContactsType represents a list of contacts (usually registrar or registrant) found in a Whois entry + + + + + A contact found in a Whois entry + + + + + + + + + + The Contact_ID corresponds to an ID for the contact. This can be presented as Contact ID, Billing ID, Admin ID, Tech ID, etc. + + + + + The name of the contact + + + + + The email address of the contact + + + + + The phone number of the contact + + + + + The address of the contact + + + + + + The contact_type field specifies what type of contact this is. Only values from WhoisObj:RegistrarContactTypeEnum can be used. + + + + + + + + + + The RegistrarContactTypeEnum defines the types of registrar contacts listed in a whois entry + + + + + The contact is an administrator + + + + + The contact is for billing + + + + + The contact is for technical assistance + + + + + + + + The WhoisStatusType specifies a status for a domain as listed in its Whois entry. Only statuses defined by WhoisStatusTypeEnum can be used. + + + + + + + + + + + + + The WhoisStatusesType defines a list of WhoisStatusType objecst + + + + + + + + + The WhoisNameserversType defines a list of nameservers associated with a Whois entry + + + + + The Nameserver field specifies a nameserver of the domain for this whois entry + + + + + + + + + + + + The Registrant_ID specifies the registrant id for a given registrant + + + + + + + + + + The WhoisRegistrantsType represents a list of registrant information for a given Whois entry + + + + + + + + + The RegionalRegistryType specifies a Regional Internet Registry (RIR) for a given WHOIS entry. RIRs defined by the RegionalRegistryTypeEnum may be used, as well as those specified by a free form text string. + + + + + + + + + + + + + The RegionalRegistryTypeEnum is an enumeration of Regional Internet Registries (RIRs) names, represente via their respective acronyms. + + + + + AfriNIC stands for African Network Information Centre, and is the RIR for Africa. + + + + + ARIN stands for American Registry for Internet Numbers, and is the RIR for the United States, Canada, several parts of the Caribbean Region, and Antarctica. + + + + + APNIC stands for Asia-Pacific Network Information Centre, and is the RIR for Asia, Australia, New Zealand, and neighboring countries. + + + + + LACNIC stands for Latin American and Caribbean Network Information Centre, and is the RIR for Latin America and parts of the Caribbean region. + + + + + RIPE NCC stands for Réseaux IP Européens Network Coordination Centre, and is the RIR for Europe, Russia, the Middle East, and Central Asia. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Computer_Account_Object.xsd b/stix_validator/schema/cybox/objects/Win_Computer_Account_Object.xsd new file mode 100755 index 0000000..933c0c7 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Computer_Account_Object.xsd @@ -0,0 +1,135 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Computer_Account_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + The Windows_Computer_Account object is intended to characterize Windows computer accounts. + + + + + The WinComputerAccountObject type is intended to characterize Windows computer accounts. + + + + + + + The Fully_Qualified_Name field refers to the fully qualified name(s) of the Windows computer account. + + + + + The Kerberos field specifies the Kerberos authentication protocol specific Object properties for the Windows computer account. + + + + + The Security_ID field specifies the Security ID (SID) value assigned to the Windows computer account. + + + + + The Security_Type field specifies the type of Security ID (SID) assigned to the Windows computer account. + + + + + The Type field specifies the type of the Windows computer account. + + + + + + + + + The FullyQualifiedNameType type refers to the fully qualified name(s) of the Windows computer account. + + + + + The NetBEUI_Name field specifies the NETBEUI name of the Windows computer account. + + + + + The Full_Name field specifies the full name of the Windows computer account. + + + + + + + The KerberosType type specifies the Kerberos authentication protocol specific Object properties for the Windows computer account. + + + + + The Delegation field specifies the Kerberos delegation used for the Windows computer account. + + + + + The Ticket field specifies the ID of the Kerberos ticket assigned to the Windows computer account. + + + + + + + The Delegation field specifies the Kerberos delegation used for the Windows computer account. + + + + + The Bitmask field specifies the bitmask used in the Kerberos delegation for the Windows computer account. + + + + + The Service field specifies the properties of the Kerberos delegation service for the Windows computer account. + + + + + + + The KerberosServiceType specifies the properties of the Kerberos delegation service for the Windows computer account. + + + + + The Computer field specifies the computer name for the Kerberos service. + + + + + The Name field specifies the name of the Kerberos service. + + + + + The Port field specifies the port for the Kerberos service. + + + + + The User field specifies the username for the Kerberos service. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Critical_Section_Object.xsd b/stix_validator/schema/cybox/objects/Win_Critical_Section_Object.xsd new file mode 100755 index 0000000..898b194 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Critical_Section_Object.xsd @@ -0,0 +1,40 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Critical_Section_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Windows_Critical_Section object is intended to characterize Windows Critical Section objects. + + + + + The WindowsCriticalSectionObjectType type is intended to characterize Windows Critical Section objects. + + + + + + + The Address field specifies the address of the code that crated the critical section object. + + + + + The Spin_Count field specifies the spin count value for the critical section object. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Driver_Object.xsd b/stix_validator/schema/cybox/objects/Win_Driver_Object.xsd new file mode 100755 index 0000000..f7d7f71 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Driver_Object.xsd @@ -0,0 +1,269 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Driver_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Windows_Driver object is intended to characterize Windows device drivers. + + + + + The WindowsDriverObject type is intended to characterize Windows device drivers. + + + + + + + The Device_Object_List field specifies the device objects that were created by the driver. + + + + + The Driver_Init field specifies the entry point for the driver's DriverEntry routine. See also: http://msdn.microsoft.com/en-us/library/windows/hardware/ff544174(v=vs.85).aspx + + + + + The Driver_Name field specifies the name of the driver. + + + + + The Driver_Object_Address field specifies the address to the driver's driver object, which contains the storage for the entry point to many of the driver's standard routines. See also: http://msdn.microsoft.com/en-us/library/windows/hardware/ff548034(v=vs.85).aspx + + + + + The Driver_Start_IO field specifies the entry point for the driver's StartIO routine. See also: http://msdn.microsoft.com/en-us/library/windows/hardware/ff544174(v=vs.85).aspx + + + + + The Driver_Unload field specifies the entry point for the driver's unload routine. See also: http://msdn.microsoft.com/en-us/library/windows/hardware/ff544174(v=vs.85).aspx + + + + + The Image_Base field specifies the preferred address of the first byte of the driver's image when it is loaded into memory. + + + + + The Image_Size field specifies the size of the driver's image, in bytes. + + + + + The IRP_MJ_CLEANUP field represents a count of the number of times the CLEANUP function code was processed by the driver. + + + + + The IRP_MJ_CLOSE field represents a count of the number of times the CLOSE function code was processed by the driver. + + + + + The IRP_MJ_CREATE field represents a count of the number of times the CREATE function code was processed by the driver. + + + + + The IRP_MJ_CREATE_MAILSLOT field represents a count of the number of times the CREATE_MAILSLOT function code was processed by the driver. + + + + + The IRP_MJ_CREATE_NAMED_PIPE field represents a count of the number of times the CREATE_NAMED_PIPE function code was processed by the driver. + + + + + The IRP_MJ_DEVICE_CHANGE field represents a count of the number of times the DEVICE_CHANGE function code was processed by the driver. + + + + + The IRP_MJ_DEVICE_CONTROL field represents a count of the number of times the DEVICE_CONTROL function code was processed by the driver. + + + + + The IRP_MJ_DIRECTORY_CONTROL field represents a count of the number of times the DIRECTORY_CONTROL function code was processed by the driver. + + + + + The IRP_MJ_FILE_SYSTEM_CONTROL field represents a count of the number of times the FILE_SYSTEM_CONTROL function code was processed by the driver. + + + + + The IRP_MJ_FLUSH_BUFFERS field represents a count of the number of times the FLUSH_BUFFERS function code was processed by the driver. + + + + + The IRP_MJ_INTERNAL_DEVICE_CONTROL field represents a count of the number of times the INTERNAL_DEVICE_CONTROL function code was processed by the driver. + + + + + The IRP_MJ_LOCK_CONROL field represents a count of the number of times the LOCK_CONROL function code was processed by the driver. + + + + + The IRP_MJ_PNP field represents a count of the number of times the PNP function code was processed by the driver. + + + + + The IRP_MJ_POWER field represents a count of the number of times the POWER function code was processed by the driver. + + + + + The IRP_MJ_READ field represents a count of the number of times the READ function code was processed by the driver. + + + + + The IRP_MJ_QUERY_EA field represents a count of the number of times the QUERY_EA function code was processed by the driver. + + + + + The IRP_MJ_QUERY_INFORMATION field represents a count of the number of times the QUERY_INFORMATION function code was processed by the driver. + + + + + The IRP_MJ_QUERY_SECURITY field represents a count of the number of times the QUERY_SECURITY function code was processed by the driver. + + + + + The IRP_MJ_QUERY_QUOTA field represents a count of the number of times the QUERY_QUOTA function code was processed by the driver. + + + + + The IRP_MJ_QUERY_VOLUME_INFORMATION field represents a count of the number of times the QUERY_VOLUME_INFORMATION function code was processed by the driver. + + + + + The IRP_MJ_SET_EA field represents a count of the number of times the SET_EA function code was processed by the driver. + + + + + The IRP_MJ_SET_INFORMATION field represents a count of the number of times the SET_INFORMATION function code was processed by the driver. + + + + + The IRP_MJ_SET_SECURITY field represents a count of the number of times the SET_SECURITY function code was processed by the driver. + + + + + The IRP_MJ_SET_QUOTA field represents a count of the number of times the SET_QUOTA function code was processed by the driver. + + + + + The IRP_MJ_SET_VOLUME_INFORMATION field represents a count of the number of times the SET_VOLUME_INFORMATION function code was processed by the driver. + + + + + The IRP_MJ_SHUTDOWN field represents a count of the number of times the SHUTDOWN function code was processed by the driver. + + + + + The IRP_MJ_SYSTEM_CONTROL field represents a count of the number of times the SYSTEM_CONTROL function code was processed by the driver. + + + + + The IRP_MJ_WRITE field represents a count of the number of times the WRITE function code was processed by the driver. + + + + + + + + + The DeviceObjectStructType type specifies the properties of a device object. In this context, a device object represents a logical, virtual, or physical device for which a driver handles I/O requests. See also: http://msdn.microsoft.com/en-us/library/windows/hardware/ff543147(v=vs.85).aspx + + + + + The Attached_Device_Name field specifies the name of another device object that was attached to this one. See also: http://msdn.microsoft.com/en-us/library/windows/hardware/ff543147(v=vs.85).aspx + + + + + The Attached_Device_Object field specifies a pointer to another device object that was attached to this one. Typically this is a filter driver. See also: http://msdn.microsoft.com/en-us/library/windows/hardware/ff543147(v=vs.85).aspx + + + + + The Attached_To_Device_Name field specifies the name of another device object that this one was attached to. + + + + + The Attached_To_Device_Object field specifies a pointer to another device object that this one was attached to. + + + + + The Attached_To_Driver_Object field specifies a pointer to the driver to which this device object was attached. + + + + + The Attached_To_Driver_Name field specifies the name of the driver to which this device object was attached. + + + + + The Device_Name field specifies the name of the device object. + + + + + The Device_Object field specifies a pointer to the driver object for the caller. + + + + + + + The DeviceObjectListType specifies a list of device objects. + + + + + The Device_Object _Struct field specifies a single device object utilizing the Windows Driver Device Object Struct. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Event_Log_Object.xsd b/stix_validator/schema/cybox/objects/Win_Event_Log_Object.xsd new file mode 100755 index 0000000..5638545 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Event_Log_Object.xsd @@ -0,0 +1,137 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Event_Log_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Windows_Event_Log object is intended to characterize entries in the Windows event log. Microsoft's Event schema is described at http://msdn.microsoft.com/en-us/library/aa385201 and the .NET API is described at http://msdn.microsoft.com/en-us/library/y80k1300.aspx + + + + + The WindowsEventLogObjectType type is intended to characterize entries in the Windows event log. + + + + + + + The EID field specifies the ID of the event for which the event log entry was created. + + + + + The event type associated with the entry in the event log, e.g., warning, information, error. + + + + + The name of the log. + + + + + The rendered message string for the event. + + + + + The event entry's category number, as defined by the source. + + + + + The text associated with Category_Num. + + + + + The Generation_Time field specifies the date/time the event was generated. + + + + + What logged the event, typically the name of an application or sub-component. + + + + + The name of the computer on which the event log entry was generated. + + + + + The name of the user (the security ID) responsible for the event. + + + + + The event data as a binary blob. + + + + + A globally unique identifier that identifies the current activity. + + + + + A globally unique identifier that identifies the activity to which control was transferred to. + + + + + The Execution_Process_ID field specifies the Process ID (PID) of the process which created the event. + + + + + The Execution_Thread_ID field specifies the Thread ID (TID) of the thread which created the event. + + + + + The index of the event entry in the log. + + + + + A DWORD value that is always set to ELF_LOG_SIGNATURE (the value 0x654c664c), which is ASCII for eLfL. + + + + + List of unformatted messages in the event log entry. + + + + + The Write_Time field specifies the date/time that the entry was written into the event log. + + + + + + + + + The UnformattedMessageListType type is a list of unformatted messages in the event log entry. + + + + + A single unformatted message in the event log entry. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Event_Object.xsd b/stix_validator/schema/cybox/objects/Win_Event_Object.xsd new file mode 100755 index 0000000..d39670d --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Event_Object.xsd @@ -0,0 +1,80 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Event_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Windows_Event object is intended to characterize Windows event (synchronization) objects. + + + + + The WindowsEventObjectType type is intended to characterize Windows event (synchronization) objects. + + + + + + + The Handle field specifies the handle to the Windows event object. It imports and uses the WindowsHandleObjectType type from the CybOX Windows Handle object. + + + + + The Name field specifies the name of the Windows event object. + + + + + The Type field specifies the type of the Windows event. + + + + + + + + + WinEventType specifies Windows event types, via a union of the WinEventTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The WinEventTypeEnum type is an enumeration of Windows synchronization event types. These are described in detail in http://msdn.microsoft.com/en-us/library/windows/desktop/ms682655(v=vs.85).aspx. + + + + + Indicates an event object whose state remains signaled until it is explicitly reset to nonsignaled by the ResetEvent function. While it is signaled, any number of waiting threads, or threads that subsequently specify the same event object in one of the wait functions, can be released. + + + + + Indicates an event object whose state remains signaled until a single waiting thread is released, at which time the system automatically sets the state to nonsignaled. If no threads are waiting, the event object's state remains signaled. If more than one thread is waiting, a waiting thread is selected. Do not assume a first-in, first-out (FIFO) order. External events such as kernel-mode APCs can change the wait order. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Executable_File_Object.xsd b/stix_validator/schema/cybox/objects/Win_Executable_File_Object.xsd new file mode 100755 index 0000000..47931ee --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Executable_File_Object.xsd @@ -0,0 +1,1333 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Executable_File_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Windows_Executable_File object is intended to characterize Windows PE (Portable Executable) files. Sources of information: Matt Pietrik's articles in MSDN Magazine (http://msdn.microsoft.com/en-us/magazine/cc301805.aspx and http://msdn.microsoft.com/en-us/magazine/cc301808.aspx); Microsoft's specification of PE and COFF (http://msdn.microsoft.com/library/windows/hardware/gg463125); LUEVELSMEYER's description (http://webster.cs.ucr.edu/Page_TechDocs/pe.txt). + + + + + The Resource field characterizes an abstract PE file resource. + + + + + The VersionInfoResource field characterizes a Version resource that uses the VERSIONINFO resource. + + + + + The WindowsExecutableFileObjectType type is intended to characterize Windows PE (Portable Executable) files. + + + + + + + The Build_Information field specifies some information on the tools used to build the PE binary. + + + + + The Digital_Signature field specifies the information about the digital signature used to sign the PE binary. + + + + + The Exports field characterizes the PE Export table of the PE Binary. + + + + + The Extraneous_Bytes field specifies the number of extraneous bytes contained in the PE binary. + + + + + The Headers property contains fields for characterizing aspects the various types of PE headers. + + + + + The Imports property characterizes the PE Import Table of the binary. + + + + + The PE_Checksum property specifies the checksum of the PE file. + + + + + The Resources field characterizes the PE Resources of the binary. + + + + + The Sections field characterizes the PE Sections of the binary. + + + + + The Type specifies the particular type of the PE binary, e.g. Executable. + + + + + + + + + The PECheckSumType records the checksum of the PE file, both as found in the file and computed. + + + + + PE_Computed_API specifies a checksum computed by an external algorithm. + + + + + PE_File_API specifed the checksum computed by IMAGHELP.DLL. + + + + + PE_File_Raw specifies the checksum found in the PE file (in the Optional Header). + + + + + + + PEExportsType specifies the PE File exports data section. The exports data section contains information about symbols exported by the PE File (a DLL) which can be dynamically loaded by other executables. This type abstracts, and its components, abstract the Windows structures. + + + + + A list of the exported functions in this section. + + + + + The date and time the export data was created. + + + + + The number of addresses in the export data section's address table. + + + + + The number of names in the export data section's name table. + + + + + + + PEExportedFunctionsType specifies a list of PE exported functions + + + + + Specifies a single field in the list of exported functions. + + + + + + + Specifies a list of sections that appear in the PE file. + + + + + Specifies an field of a list of PE file sections. + + + + + + + Specifies the result of an entropy computation. + + + + + Specifies the computed entropy value. + + + + + Specifies the smallest possible value for the entropy computation. + + + + + Specifies the largest possible value for the entropy computation (eg., this would be 8 if the entropy computations is based on bits of information). + + + + + + + The PEImportType type is intended as container for the properties relevant to PE binary imports. + + + + + The File_Name field specifies the name of the library (file) that the PE binary imports. + + + + + The Imported_Functions field is used to enumerate any functions imported from a particular library. + + + + + The Virtual_Address field specifies the relative virtual address (RVA) of the PE binary library import. + + + + + + The delay_load field is a boolean value that is intended to describe whether a PE binary import is delay-load or not. + + + + + The initially_visible field refers to whether the import is initially visible, with regards to being initially visible or hidden in relation to PE binary packing. A packed binary will typically have few initially visible imports, and thus it is necessary to make the distinction between those that are visible initially or only after the binary is unpacked. + + + + + + A list of PE imported functions + + + + + Specifies a single field in a list of imported functions. + + + + + + + The PEResourceType type is intended as container for the properties relevant to PE binary resources. + + + + + This field refers to the type of data referred to by this resource. + + + + + The Name field specifies the name of the resource used by the PE binary. + + + + + The Hashes field is used to include any hash values computed using the specified PE binary resource as input. + + + + + + + The PEVersionInfoResourceType characterizes the special VERSIONINFO resource type. For more information please see: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381058(v=vs.85).aspx + + + + + + + The Comments field captures any additional information that should be displayed for diagnostic purposes. + + + + + The CompanyName field captures the company that produced the file - for example, "Microsoft Corporation" or "Standard Microsystems Corporation, Inc." + + + + + The FileDescription field captures the file description to be presented to users. This string may be displayed in a list box when the user is choosing files to install - for example, "Keyboard Driver for AT-Style Keyboards". + + + + + The FileVersion field captures the version number of the file - for example, "3.10" or "5.00.RC2". + + + + + The InternalName field captures the internal name of the file, if one exists - for example, a module name if the file is a dynamic-link library. If the file has no internal name, this string should be the original filename, without extension. + + + + + The LangID field captures the localization language identifier specified in the version-information resource. + + + + + The LegalCopyright field captures the copyright notices that apply to the file. This should include the full text of all notices, legal symbols, copyright dates, and so on. + + + + + The LegalTrademarks field captures the trademarks and registered trademarks that apply to the file. This should include the full text of all notices, legal symbols, trademark numbers, and so on. + + + + + The OriginalFilename field captures the original name of the file, not including a path. This information enables an application to determine whether a file has been renamed by a user. The format of the name depends on the file system for which the file was created. + + + + + The PrivateBuild field captures the information about a private version of the file - for example, "Built by TESTER1 on \TESTBED". This string should be present only if VS_FF_PRIVATEBUILD is specified in the fileflags parameter of the root block. + + + + + The ProductName field captures the name of the product with which the file is distributed. This string is required. + + + + + The ProductVersion field captures the version of the product with which the file is distributed - for example, "3.10" or "5.00.RC2". + + + + + The SpecialBuild field captures the text that indicates how this version of the file differs from the standard version - for example, "Private build for TESTER1 solving mouse problems on M250 and M250E computers". This string should be present only if VS_FF_SPECIALBUILD is specified in the fileflags parameter of the root block. + + + + + + + + + PEExportType sepcifies the type describing exported functions. + + + + + The Function_Name field specifies the name of the function exported by the PE binary. + + + + + The Entry_Point field specifies the entry point of the function exported by the PE binary. + + + + + The Ordinal field specifies the ordinal value (index) of the function exported by the PE binary. + + + + + + + PEResourceListType specifies a list of resources found in the PE file. + + + + + Specifies an field of a list of resources. + + + + + + + PEImportedFunctionType specifies the type describing imported functions. + + + + + The Function_Name field specifies the name of the function from the specified library that the PE binary imports. + + + + + The Hint field specifies the index into the export table of the library that the function is found in. + + + + + The Ordinal field specifies the ordinal value (index) of the function in the library that is found in. + + + + + The Bound field specifies the precomputed address if the imported function is bound. + + + + + The Virtual_Address field specifies the relative virtual address (RVA) of the PE binary library imported function. + + + + + + + PEImportListType specifies a list of functions in an import data section. + + + + + Specifies a single field in a list of imported functions. + + + + + + + The PESectionType type is intended as container for the properties relevant to PE binary sections. A PE Section consists of a header and data. The PESectionType contains properties that describe the Section Header and metadata computed about the section (e.g., hashes, entropy). + + + + + The Section_Header property contains characteristics of the section's section header structure. + + + + + The Data_Hashes field is used to include any hash values computed using the data contained in the specified PE binary section as input. + + + + + The Entropy field specifies the calculated entropy of the PE binary section. + + + + + The Header_Hashes field is used to include any hash values computed using the header of the specified PE binary section as input. + + + + + Specifies the type of the section. + + + + + + + The PEDataDirectoryStruct type is intended as container for the properties relevant to a PE binary's data directory structure. + + + + + The Virtual_Address field specifies the relative virtual address (RVA) of the data structure. + + + + + The size field specifies the size of the data structure, in bytes. + + + + + + + The PESectionHeaderStruct type is intended as container for the properties relevant to a PE binary's section header structure. + + + + + The Name field specifies the name of the PE binary section. + + + + + The Virtual_Size field is the total size of the PE binary section when loaded into memory. It is valid only for executables and should be 0 for object files. + + + + + The Virtual_Address field specifies the relative virtual address (RVA) of the PE binary section. + + + + + The Size_Of_Raw_Data field specifies the size of the data contained in the PE binary section. + + + + + The Pointer_To_Raw_Data field specifies the file offset of the beginning of the PE binary section. + + + + + The Pointer_To_Relocations field specifies the offset of the PE binary section relocations, if applicable. + + + + + Specifies the beginning of line-number entries for the section. Should be 0. + + + + + The Number_Of_Relocations field specifies the number of relocations defined for the specified PE binary section. + + + + + Specifies the number of line number entreis for the section. Should be 0. + + + + + The Characteristics field specifies any flags defined for the specified PE binary section. + + + + + + + The DOSHeaderType type is a container for the characteristics of the _IMAGE_DOS_HEADER structure, which can be found in Winnt.h and pe.h. See http://www.csn.ul.ie/~caolan/pub/winresdump/winresdump/doc/pefile.html for more information about the winnt.h file, and http://www.tavi.co.uk/phobos/exeformat.html for even more clarification. + + + + + Specifies the magic number, specifically the Windows OS signature value, which can either take on MZ for DOS (which is, for all intensive purposes, MOST Windows executables), NE for OS2, LE for OS2 LE, or PE00 for NT. + + + + + Specifies the number of bytes actually used in the last page, with the special case of a full page being represented by a value of zero (since the last page is never empty). For example, assuming a page size of 512 bytes, this value would be 0x0000 for a 1024 byte file, and 0x0001 for a 1025 byte file (since it only contains one valid byte). + + + + + Specifies the the number of pages required to hold the file. For example, if the file contains 1024 bytes, and we assume the file has pages of a size of 512 bytes, this word would contain 0x0002; if the file contains 1025 bytes, this word would contain 0x0003. + + + + + Specifies the number of relocation items, i.e. the number of entries that exist in the relocation pointer table. If there are no relocation entries, this value is zero. + + + + + Specifies the size of the executable header in terms of paragraphs (16 byte chunks). It indicates the offset of the program's compiled/assembled and linked image (the load module) within the executable file. The size of the load module can be deduced by subtracting this value (converted to bytes) from the overall file size derived from combining the e_cp (number of file pages) and e_cblp (number of bytes in last page) values. The header always spans an even number of paragraphs. + + + + + Specifies the minimum number of extra paragraphs needed to be allocated to begin execution. This is IN ADDITION to the memory required to hold the load module. This value normally represents the total size of any uninitialised data and/or stack segments that are linked at the end of a program. This space is not directly included in the load module, since there are no particular initializing values and it would simply waste disk space. + + + + + Specifies the maximum number of extra paragraphs needed to be allocated by the program before it begins execution. This indicates ADDITIONAL memory over and above that required by the load module and the value specified by MINALLOC. If the request cannot be satisfied, the program is allocated as much memory as is available. + + + + + Specifies the initial SS value, which is the paragraph address of the stack segment relative to the start of the load module. At load time, this value is relocated by adding the address of the start segment of the program to it, and the resulting value is placed in the SS register before the program is started. In DOS, the start segment of the program is the first segment boundary in memory after the PSP. + + + + + Specifies the initial SP value, which is the absolute value that must be loaded into the SP register before the program is given control. Since the actual stack segment is determined by the loader, and this is merely a value within that segment, it does not need to be relocated. + + + + + Specifies the checksum of the contents of the executable file. It is used to ensure the integrity of the data within the file. For full details on how this checksum is calculated, see http://www.tavi.co.uk/phobos/exeformat.html#checksum. + + + + + Specifies the initial IP value, which is the absolute value that should be loaded into the IP register in order to transfer control to the program. Since the actual code segment is determined by the loader, and this is merely a value within that segment, it does not need to be relocated. + + + + + Specifies the pre-relocated initial CS value, relative to the start of the load module, that should be placed in the CS register in order to transfer control to the program. At load time, this value is relocated by adding the address of the start segment of the program to it, and the resulting value is placed in the CS register when control is transferred. + + + + + Specifies the file address of the relocation table, or more specifically, the offset from the start of the file to the relocation pointer table. This value must be used to locate the relocation pointer table (rather than assuming a fixed location) because variable-length information pertaining to program overlays can occur before this table, causing its position to vary. A value of 0x40 in this field generally indicates a different kind of executable file, not a DOS 'MZ' type. + + + + + Specifies the overlay number, which is normally set to 0x0000, because few programs actually have overlays. It changes only in files containing programs that use overlays. See http://www.tavi.co.uk/phobos/exeformat.html#overlaynote for more information about overlays. + + + + + Specifies reserved words for the program (known in winnt.h as e_res[4]), usually set to zero by the linker. In this case, just use a single reserved1 set to zero; if not zero create four reserved1 with the correct value. + + + + + Specifies the identifier for the OEM for e_oeminfo. + + + + + Specifies the OEM information for a specific value of e_oeminfo. + + + + + Specifies reserved words for the program (known in winnt.h as e_res[10]), usually set to zero by the linker. In this case, just use a single reserved1 set to zero; if not zero create ten reserved1 with the correct value. + + + + + Specifies the file adress of the of the new exe header. In particular, it is a 4-byte offset into the file where the PE file header is located. It is necessary to use this offset to locate the PE header in the file. + + + + + The Hashes field is used to include any hash values computed using the specified PE binary MS-DOS header as input. + + + + + + + PEHeaderType specifies the headers found in PE and COFF files. + + + + + The DOS_Header property refers to the MS-DOS PE header and its associated characteristics. + + + + + The Signature property specifies the 4-bytes sugnature that identifies the file as a PE file. + + + + + The File_Header property refers to the PE file header (somtimes referred to as the COFF header) and its associated characteristics. + + + + + The Optional_Header field refers to the PE optional header and its associated characteristics. The Optional Header is required for executable (PE) files, but optional for object (COFF) files. + + + + + The Entropy field specifies the calculated entropy of the PE file header. + + + + + The Hashes field is used to include any hash values computed using the specified PE binary file header as input. + + + + + + + The PEFileHeaderType type refers to the PE file header (somtimes referred to as the COFF header) and its associated characteristics. + + + + + Specifies the type of target machine. + + + + + Specifies the number of sections in the file. + + + + + Specifies the time when the file was created (the low 32 bits of the number of seconds since epoch). + + + + + Specifies the file offset of the COFF symbol table (should be 0). + + + + + Specifies the number of entries in the symbol table. Should be 0. + + + + + Specifies the size of the optional header. Should be 0 for object files and non-zero for executables. + + + + + Specifies the flags that indicate the file's characteristics. + + + + + Any hashes computed for the Optional Header. + + + + + + + SubsystemTypes specifies subsystem types via a union of the SubsystemTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + PEType specifies PE file types via a union of the PETypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + SectionTypes specifies PE section types via a union of the SectionTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The PEOptionalHeaderType type describes the PE Optional Header structure. Additional computed metadata, e.g., hashes of the header, are also included. + + + + + Specifies the unsigned integer that indicates the type of executable file. + + + + + Specifies the linker major version number. + + + + + Specifies the linker minor version number. + + + + + Specifies the size of the code (text) section. If there are multiple sections, size is the sum of the sizes if each. + + + + + Specifies the size of the initialized data section. If there are multiple sections, size is the sum of the sizes if each. + + + + + Specifies the size of the uninitialized (bss) data section. If there are multiple sections, size is the sum of the sizes if each. + + + + + Specifies the address of the entry point relative to the image base when the executable is loaded into memory. When there is no entry point (e.g., optional for DLLs), the value should be 0. + + + + + Specifies the address that is relative to the image base of the beginning-of-code section when it is loaded into memory. + + + + + Specifies the address that is relative to the image base of the beginning-of-data section when it is loaded into memory. + + + + + Specifies the preferred address of the first byte of image when loaded into memory; must be a multiple of 64 K. + + + + + Specifies the alignment (in bytes) of sections when they are loaded into memory. + + + + + Specifies the factor (in bytes) that is used to align the raw data of sections in the image file. + + + + + Specifies the major version number of the required operating system. + + + + + Specifies the minor version number of the required operating system. + + + + + Specifies the major version number of the image. + + + + + Specifies the minor version number of the image. + + + + + Specifies the major version number of the subsystem. + + + + + Specifies the minor version number of the subsystem. + + + + + Reserved; must be 0. + + + + + Specifies the size (in bytes) of the image, including all headers, as the image is loaded in memory. + + + + + Specifies the combined size of the MS DOS header, PE header, and section headers rounded up to a multiple of FileAlignment. + + + + + Specifies the checksum of the PE file. + + + + + Specifies the subsystem (e.g., GUI, device driver) that is required to run this image. + + + + + Specifies flags that characterize the PE file. + + + + + Specifies the size of the stack to reserve. + + + + + Specifies the size of the stack to commit. + + + + + Specifies the size of the local heap space to reserve. + + + + + Specifies the size of the local heap space to commit. + + + + + Reserved; must be 0. + + + + + Specifieshe number of data-directory entries in the remainder of the optional header. + + + + + Specifies the data directories in the remainder in the optional header. This field will be repeated for each data directory. + + + + + The Hashes field is used to include any hash values computed using the specified PE binary optional header as input. + + + + + + + The DataDirectoryType specifies the data directories that can appear in the PE file's optional header. The data directories, except the Certificate Table, are loaded into memory so they can be used at runtime. + + + + + Specifies the export table data directory. + + + + + Specifies the import table data directory. + + + + + Specifies the resource table data directory. + + + + + Specifies the exception table data directory. + + + + + Specifies the certificate table data directory. The table of certificates is in a file which the data directory points to. + + + + + Specifies the base relocation table data directory. + + + + + Specifies the debug data directory. + + + + + Reserved, must be 0. + + + + + Specifies the RVA of the value to be stored in the global pointer register. + + + + + Specifies the thread local storage (TLS) table data directory. + + + + + Specifies the load configuration table data directory. + + + + + Specifies the bound import table data directory. + + + + + Specifies the import address table (IAT) data directory. + + + + + Specifies the delay import descriptor data directory. + + + + + Specifies the Common Language Runtime (CLR) header data directory. + + + + + Reserved; must be 0. + + + + + + + The PEBuildInformationType captures information about the tools used to build the PE binary, including the compiler and linker. + + + + + The Linker_Name field specifies the name of the linker used to link the PE binary. + + + + + The Linker_Version field specifies the version of the linker used to link the PE binary. + + + + + The Compiler_Name field specifies the name of the compiler used to compile the binary. + + + + + The Compiler_Version field specifies the version of the compiler used to compile the binary. + + + + + + + SectionTypeEnum enumerates the types of PE sections in an executable. See http://www.silurian.com/inspect/peformat.htm for more information. These sections can be viewed in a Disassembler, such as IDA and more specifically in the freeware CFF Explorer. + + + + + Denoted by .text, this specifies the main program code--usually execute and read access only. + + + + + Denoted by .data, this specifies main initialized data code that is used by the program. + + + + + Denoted by .rsrc, this specifies Windows Resource data. + + + + + Denoted by .rdata, this specifies read only data. + + + + + Denoted by .reloc, this specifies base relocations. + + + + + Denoted by .debug, this specifies debug information. + + + + + Denoted by .idata, this specifies imported function data. + + + + + Denoted by .tls, this specifies Thread Local Storage. Data is private to each thread. + + + + + Denoted by .CRT, this specifies data reserved for the C Run-Time library. + + + + + + + SubsystemTypeEnum enumerates the types of subsystems in Windows an executable can be compatible for, according to winnt.h and more specifically, the Subsystem value of the IMAGE_OPTIONAL_HEADER structure. See http://source.winehq.org/source/include/winnt.h and http://msdn.microsoft.com/en-us/library/windows/desktop/ms680339(v=vs.85).aspx for more information. + + + + + Specifies an unknown subsystem. + + + + + Specifies that no subsystem is required to run the image (i.e. only device drivers and native system processes are needed). + + + + + Specifies the Windows Graphical user interface (GUI) subsystem. + + + + + Specifies the Windows character-mode user interface (CUI) subsystem. + + + + + Specifies the OS/2 CUI subsystem. + + + + + Specifies the POSIX CUI subsystem. + + + + + Specifies the Native Windows 9x drivers. This is denoted by the value IMAGE_SUBSYSTEM_NATIVE_WINDOWS or 0x8. + + + + + Specifies the Windows CE system with a GUI. + + + + + Specifies the Extensible Firmware Interface (EFI) application. + + + + + Specifies the Extensible Firmware Interface (EFI) driver with boot services. + + + + + Specifies the Extensible Firmware Interface (EFI) driver with run-time services. + + + + + Specifies the Extensible Firmware Interface (EFI) image. + + + + + Specifies the XBOX system. + + + + + Specifies the Windows Boot application. + + + + + + + PETypeEnum enumerates the characteristics flags for the executable file in question. These are detailed in winnt.h. + + + + + Specifies an executable image (not an OBJ or LIB). + + + + + Specifies a dynamic link library, not a program. + + + + + Specifies an invalid executable file (i.e. not one of the listed types). + + + + + + + The PEResourceTypeEnum is a non-exhaustive enumeration of PE resource types. + + + + + The resource specified is a cursor or animated cursor defined by naming it and specifying the name of the file that contains it. (To use a particular cursor, the application requests it by name.) + + + + + The resource specified is a bitmap defined by naming it and specifying the name of the file that contains it. (To use a particular cursor, the application requests it by name.) + + + + + The resource specified is an icon or animated icon by naming it and specifying the name of the file that contains it. (To use a particular icon, the application requests it by name.) + + + + + The resource specified defines the appearance and function of a menu. Does not define help or regular identifiers, nor uses the MFT_* type and MFS_* state flags. + + + + + The resource specified defines the appearance and function of a menu, which can also utilize help or regular identifiers, as well as the MFT_* type and MFS_* state flags. + + + + + The resource specified defines a menu item that can contain menu items and submenus. + + + + + The resource specified defines a template that an application can use to create dialog boxes. This type is considered obsolete in Windows and newer applications use the DIALOGEX resource. + + + + + The resource specified defines a template that newer applications can use to create dialog boxes. + + + + + + + + + + The resource specified defines string resources. String resources are Unicode or ASCII strings that can be loaded from the executable file. + + + + + + + + + + The resource specified defines the name of a file that contains a font. + + + + + The resource specified defines menu accelerator keys. + + + + + The resource specified defines data resources. Data resources let you include binary data in the executable file. + + + + + The resource specified defines a message table by naming it and specifying the name of the file that contains it. The file is a binary resource file generated by the message compiler. + + + + + + + + + + + + + + + The resource specified defines version-information. Vontains information such as the version number, intended operating system, and so on. + + + + + + + + + + This resource is obsolete and included for completeness. + + + + + This is a special resource that is interpreted by Visual C++. For more information see http://go.microsoft.com/FWLink/?LinkId=83951. + + + + + This is a special resource that is used with /TLBID and /TLBOUT linker options. For more information see http://go.microsoft.com/FWLink/?LinkId=83960 (for /TLBID) and http://go.microsoft.com/FWLink/?LinkId=83947 (for /TLBOUT). + + + + + This resource is obsolete and included for completeness. + + + + + + + + + + + + + + + The resource specified defines an HTML file. + + + + + + + + + + The resource specified defines a different object than those listed. This resource type can also be considered User-Defined, i.e. defines a resource that contains application-specific data, as noted in MSDN. + + + + + diff --git a/stix_validator/schema/cybox/objects/Win_File_Object.xsd b/stix_validator/schema/cybox/objects/Win_File_Object.xsd new file mode 100755 index 0000000..ca8b003 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_File_Object.xsd @@ -0,0 +1,269 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_File_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Windows_File object is intended to characterize Windows files. + + + + + The WindowsFileObjectType type is intended to characterize Windows files. + + + + + + + The Filename_Accessed_Time field specifies the date/time the filename of the Windows file was last accessed. + + + + + The Filename_Created_Time field specifies the date/time the filename of the Windows file was created. + + + + + The Filename_Modified_Time field specifies the date/time the filename of the Windows file was last modified. + + + + + The Drive field specifies the drive letter of the drive that the file resides on. + + + + + The Security_ID field specifies the Security ID (SID) value assigned to the file. + + + + + The Security_Type field specifies the type of Security ID (SID) assigned to the file. + + + + + The Stream_List field specifies any alternate data streams contained within the file. + + + + + + + + + The StreamObjectType type is intended to characterize NTFS alternate data streams. + + + + + + + The Name field specifies the name of the alternate data stream. + + + + + The Size_In_Bytes field specifies the size of the alternate data stream, in bytes. + + + + + + + + + The StreamListType type specifies a list of NTFS alternate data streams. + + + + + The Stream field characterizes a single NTFS alternate data stream. + + + + + + + The WindowsFileAttributesType type specifies Windows file attributes. It imports and extends the FileAttributeType from the CybOX File Object. + + + + + + + The WindowsFileAttributeType specifies a single Windows file attribute. + + + + + + + + + WindowsFileAttributeType specifies Windows file attributes via a union of the FileAttributesEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The WindowsFilePermissionsType type specifies Windows file permissions. It imports and extends the FilePermissionsType from the CybOX File Object. + + + + + + + The Full_Control field specifies whether reading, writing, changing and deleting of the file is perfmitted. + + + + + The Modify field specifies whether reading and writing or deletion of the file is permitted. + + + + + The Read field specifies whether viewing or accessing of the file's contents is permitted. + + + + + The Read_And_Execute field specifies whether viewing and accessing of the file's contents as well as executing of the file is permitted. + + + + + The Write field specifies whether writing to the file is permitted. + + + + + + + + + The FileAttributesEnum type is an enumeration of Windows file attributes. These refer to the constants specified in http://msdn.microsoft.com/en-us/library/gg258117(v=vs.85).aspx. + + + + + + + Specifies a file is read only, as denoted by the constant value, 0x1. Applications can read the file, but cannot write to it or delete it. This attribute is not honored on directories. For more information as to why, see http://go.microsoft.com/FWLink/?LinkId=125896. + + + + + Specifies a file or directory is hidden, as denoted by the constant value, 0x2. It is not included in an ordinary directory listing. + + + + + Specifies a file or directory that the operating system uses a part of, or uses exclusively, as denoted by the constant value, 0x4. + + + + + Specifies a directory, as denoted by the constant value, 0x10. + + + + + Specifies a file or directory that is an archive file or directory, as denoted by the constant value, 0x20. Applications typically use this attribute to mark files for backup or removal. + + + + + Specifies a reserved system value, as denoted by the constant value, 0x40. + + + + + Specifies a file that has no other attributes set, and is only valid when this attribute is used alone, as denoted by the constant value, 0x80. + + + + + Specifies a file being used for temporary storage, as denoted by the constant value, 0x100. + + + + + Specifies a sparse file, as denoted by the constant value, 0x200. + + + + + Specifies a file or directory that has an associated reparse point, or a file that is a symbolic link, as denoted by the constant value, 0x400. + + + + + Specifies a file or directory that is compressed, as denoted by the constant value, 0x800. For a file, all of the data in the file is compressed. For a directory, compression is the default for newly created files and subdirectories. + + + + + Specifies that the data of a file is not available immediately, as denoted by the constant value, 0x1000. This attribute indicates that the file data is physically moved to offline storage. This attribute is used by Remote Storage, which is the hierarchical storage management software. Applications should not arbitrarily change this attribute. + + + + + Specifies that a file is not to be indexed by the content indexing service, as denoted by the constant value, 0x2000. + + + + + Specifies a file or directory that is encrypted, as denoted by the constant value, 0x4000. For a file, all data streams in the file are encrypted. For a directory, encryption is the default for newly created files and subdirectories. + + + + + Specifies a file or directory that is marked as deleted. + + + + + Specifies the directory or user data stream is configured with integrity (only supported on ReFS volumes), as denoted by the constant value, 0x8000. It is not included in an ordinary directory listing. The integrity setting persists with the file if it's renamed. If a file is copied the destination file will have integrity set if either the source file or destination directory have integrity set. NOTE: This flag is supported ONLY for Windows Server 8 Beta and later. + + + + + Specifies a reserved system value, as denoted by the constant value, 0x10000. + + + + + The user data stream not to be read by the background data integrity scanner (AKA scrubber), as denoted by the constant value, 0x20000. When set on a directory it only provides inheritance. This flag is only supported on Storage Spaces and ReFS volumes in Windows 8 and Windows Server 8 Beta and later. It is not included in an ordinary directory listing. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Handle_Object.xsd b/stix_validator/schema/cybox/objects/Win_Handle_Object.xsd new file mode 100755 index 0000000..8300bfa --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Handle_Object.xsd @@ -0,0 +1,186 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Handle_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Windows_Handle object is intended to characterize Windows handles. + + + + + The WindowsHandleObjectType type is intended to characterize Windows handles. + + + + + + + The ID field refers to the unique number used to identify the handle. + + + + + The Name field specifies the name of the handle. + + + + + The Type field specifies the handle type, which is equivalent to the type of Windows object that the handle refers to. + + + + + The Object_Address field specifies the address of the Windows object that the handle refers to. + + + + + The Access_Mask field specifies the access bitmask of the handle. + + + + + The Pointer_Count field specifies the count of pointer references to the Windows object that the handle refers to. + + + + + + + + + The WindowsHandleListType type specifies a list of Windows handles, for re-use in other objects. + + + + + The Handle field characterizes a single Windows handle. + + + + + + + HandleType specifies Windows handle types via a union of the HandleTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The WindowsHandleType is a non-exhaustive enumeration of Windows handle types. + + + + + Specifies an access token handle. + + + + + Specifies an event handle. + + + + + Specifies a file handle. + + + + + Specifies a file mapping handle. + + + + + Specifies a job handle. + + + + + Specifies an IO completion port handle. + + + + + Specifies a mailslot handle. + + + + + Specifies a mutex handle. + + + + + Specifies a named pipe handle. + + + + + Specifies a pipe handle. + + + + + Specifies a process handle. + + + + + Specifies a semiphore handle. + + + + + Specifies a thread handle. + + + + + Specifies a transaction handle. + + + + + Specifies a waitable timer handle. + + + + + Specifies a registry key handle. + + + + + Specifies a window handle. + + + + + Specifies a service control manager handle. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Kernel_Hook_Object.xsd b/stix_validator/schema/cybox/objects/Win_Kernel_Hook_Object.xsd new file mode 100755 index 0000000..209e4b5 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Kernel_Hook_Object.xsd @@ -0,0 +1,109 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Kernel_Hook_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Windows_Kernel_Hook object is intended to characterize Windows kernel function hooks. + + + + + The WindowsKernelHookObjectType type is intended to characterize Windows kernel function hooks. + + + + + + + The Digital_Signature_Hooked field is optional and specifies the digital signature of the hooking code. + + + + + The Digital_Signature_Hooked field is optional and specifies the digital signature of the hooked code. + + + + + The Hooking_Address field is optional and specifies the address from where the hooking occurs. + + + + + The Hook_Description field is optional and provides a description of the nature of the hook. + + + + + The Hooked_Function field specifies the name of the function that is hooked. + + + + + The Hooked_Module field specifies the name of the module that is hooked. + + + + + The Hooking_Module field specifies the name of the module that is doing the hooking. + + + + + The Type field specifies the type of hook being characterized. + + + + + + + + + KernelHookType specifies Windows kernel hook types via a union of the KernelHookTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The KernelHookTypeEnum type is a non-exhaustive enumeration of Windows kernel hook types. + + + + + Specifies a kernel hook type of IAT_API. + + + + + Specifies an inline function type of kernel hook. + + + + + Specifies an instruction hooking type of kernel hook. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Kernel_Object.xsd b/stix_validator/schema/cybox/objects/Win_Kernel_Object.xsd new file mode 100755 index 0000000..e33636b --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Kernel_Object.xsd @@ -0,0 +1,128 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Kernel_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + The Windows_Kernel object is intended to characterize Windows Kernel structures. + + + + + The WindowsKernelObjectType type is intended to characterize Windows Kernel structures. + + + + + + + The IDT field characterizes the Windows Interrupt Descriptor Table (IDT). + + + + + The SSDT field characterizes the Windows System Service Descriptor Table (SSDT). The SSDT is a structure that kernel uses to dispatch functions. KeServiceDescriptorTable is a table exported by the kernel that contains pointers to four SSDTs, one for the native API, one for user/GDI support, one of IIS SPUD (in Windows 2000), and one unused.See http://www.honeynet.org/node/438; Sven Boris Schreiber, Undocumented Windows 2000 Secrets (http://undocumented.rawol.com/sbs-w2k-2-the-windows-2000-native-api.pdf); Greg Hoglund and James Butler, Rootkits: Subverting the WIndows kernel + + + + + + + + + The SSDTEntryListType type specifies a listing of the entries in the System Service Descriptor Table (SSDT). + + + + + Specifies an entry in the System Service Descriptor Table. + + + + + + + The SSDTEntryType type specifies a single entry in the System Service Descriptor Table (SSDT). + + + + + Pointer to the system service dispatch table, an array of function addresses which is indexed by the system call number. + + + + + Pointer to an array of usage counters. + + + + + Number of entries in the system service dispatch table. + + + + + Pointer to an array of bytes, which indicate the number of bytes used by the function's arguments. + + + + + + The hooked attribute specifies whether the SSDT entry is hooked. + + + + + + The IDTEntryListType type specifies a listing of the entries in the Interrupt Descriptor Table (IDT). The IDT is specific to the I386 architecture, indicating where the Prtoetcted mode Interrupt Service Routines (ISR) are located. See http://wiki.osdev.org/Interrupt_Descriptor_Table + + + + + Specifies an entry in the Interrupt Descriptor Table. + + + + + + + The IDTEntryType type specifies a single entry in the Interrupt Descriptor Table (IDT). Entries can be interrupt gates, task gates, and trap gates. + + + + + A byte that encodes the gate type and interrupt attributes (e.g., the Descriptor Privilege Level). + + + + + Higher part of the interrupt function's offset address bits 16-31 in 32-bit, bits 32-63 in 64-bit) + + + + + Lower part of the interrupt function's offset address (bits 0-15) + + + + + In 64-bit architectures, middle part of the interrupt function's offset address (bits 16-31) + + + + + A 16-bit value that points to a code segment selector in the Global Descriptot Table. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Mailslot_Object.xsd b/stix_validator/schema/cybox/objects/Win_Mailslot_Object.xsd new file mode 100755 index 0000000..c153f61 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Mailslot_Object.xsd @@ -0,0 +1,56 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Mailslot_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Windows_Mailslot object is intended to characterize Windows mailslot objects. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365576(v=vs.85).aspx + + + + + The WindowsMailslotObjectType is intended to characterize Windows mailslot objects. + + + + + + + The Handle field specifies the open Windows handle to the mailslot. It imports and uses the WindowsHandleObjectType from the CybOX Windows Handle Object. + + + + + The Max_Message_Size field specifies the maximum message size for the mailslot, in bytes. + + + + + The Name field specifies the name of the mailslot. + + + + + The Read_Timeout field specifies the amount of time, in milliseconds, a read operation can wait for a message to be written to the mailslot before a time-out occurs. + + + + + The Security_Attributes field specifies the Windows security attributes for the mailslot. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Memory_Page_Region_Object.xsd b/stix_validator/schema/cybox/objects/Win_Memory_Page_Region_Object.xsd new file mode 100755 index 0000000..a55f283 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Memory_Page_Region_Object.xsd @@ -0,0 +1,198 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Memory_Page_Region_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Windows_Memory_Page_Region object is intended represent a single Windows memory page region. + + + + + The WindowsMemoryPageRegionObjectType type is intended to characterize Windows memory page regions. + + + + + + + The Type field specifies the type of pages in the memory page region. + + + + + The Allocation_Base_Address field specifies the base address of the memory page region when the region was first allocated. + + + + + The Allocation_Protect field specifies the memory protection option for the memory page region when the region was initially allocated. + + + + + The State field specifies the state of the memory pages in the region. + + + + + The Protect field specifies the access protection of the memory pages in the region. + + + + + + + + + MemoryPageProtectionType specifies memory protection constant types, via a union of the MemoryPageProtectionEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The MemoryPageProtectionEnum defines an enumeration of memory page protection constants. As a further reference, please see: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366786(v=vs.85).aspx + + + + + From Microsoft: "Enables execute access to the committed region of pages. An attempt to read from or write to the committed region results in an access violation." + + + + + From Microsoft: "Enables execute or read-only access to the committed region of pages. An attempt to write to the committed region results in an access violation." + + + + + From Microsoft: "Enables execute, read-only, or read/write access to the committed region of pages." + + + + + From Microsoft: "Enables execute, read-only, or copy-on-write access to a mapped view of a file mapping object. An attempt to write to a committed copy-on-write page results in a private copy of the page being made for the process. The private page is marked as PAGE_EXECUTE_READWRITE, and the change is written to the new page." + + + + + From Microsoft: "Disables all access to the committed region of pages. An attempt to read from, write to, or execute the committed region results in an access violation." + + + + + From Microsoft: "Enables read-only access to the committed region of pages. An attempt to write to the committed region results in an access violation. If Data Execution Prevention is enabled, an attempt to execute code in the committed region results in an access violation." + + + + + From Microsoft: "Enables read-only or read/write access to the committed region of pages. If Data Execution Prevention is enabled, attempting to execute code in the committed region results in an access violation." + + + + + From Microsoft: "Enables read-only or copy-on-write access to a mapped view of a file mapping object. An attempt to write to a committed copy-on-write page results in a private copy of the page being made for the process. The private page is marked as PAGE_READWRITE, and the change is written to the new page. If Data Execution Prevention is enabled, attempting to execute code in the committed region results in an access violation." + + + + + + + MemoryPageStateType specifies memory protection states, via a union of the MemoryPageStateEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The MemoryPageStateEnum defines an enumeration of memory page states. As a further reference, please see: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366775(v=vs.85).aspx + + + + + From Microsoft: "Indicates committed pages for which physical storage has been allocated, either in memory or in the paging file on disk." + + + + + From Microsoft: "Indicates free pages not accessible to the calling process and available to be allocated. For free pages, the information in the AllocationBase, AllocationProtect, Protect, and Type members is undefined." + + + + + From Microsoft: "Indicates reserved pages where a range of the process's virtual address space is reserved without any physical storage being allocated. For reserved pages, the information in the Protect member is undefined." + + + + + + + MemoryPageTypeType specifies memory protection type, via a union of the MemoryPageTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The MemoryPageTypeEnum defines an enumeration of memory page types. As a further reference, please see: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366775(v=vs.85).aspx + + + + + From Microsoft: "Indicates that the memory pages within the region are mapped into the view of an image section." + + + + + From Microsoft: "Indicates that the memory pages within the region are mapped into the view of a section." + + + + + From Microsoft: "Indicates that the memory pages within the region are private (that is, not shared by other processes)." + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Mutex_Object.xsd b/stix_validator/schema/cybox/objects/Win_Mutex_Object.xsd new file mode 100755 index 0000000..7eeb2fa --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Mutex_Object.xsd @@ -0,0 +1,42 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Mutex_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + The Windows_Mutex object is intended to characterize Windows mutual exclusion (mutex) objects. + + + + + The WindowsMutexObjectType type is intended to characterize Windows mutual exclusion (mutex) objects. + + + + + + + The Handle field specifies the open Windows handle to the mutex. It imports and uses the WindowsHandleObjectType from the CybOX Windows Handle Object. + + + + + The Security_Attributes field specifies the Windows security attributes for the mutex. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Network_Route_Entry_Object.xsd b/stix_validator/schema/cybox/objects/Win_Network_Route_Entry_Object.xsd new file mode 100755 index 0000000..858d78b --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Network_Route_Entry_Object.xsd @@ -0,0 +1,200 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Network_Route_Entry_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + he Windows_Network_Route_Entry object is intended to characterize Windows network routing table entries. + + + + + The WindowsNetworkRouteEntryObjectType type is intended to characterize Windows network routing table entries. + + + + + + + The NL_ROUTE_PROTOCOL element captures the routing protocol specified for the network route, as detailed in the NL_ROUTE_PROTOCOL enumeration. For more information please see: http://msdn.microsoft.com/en-us/library/windows/desktop/aa814494(v=vs.85).aspx + + + + + The NL_ROUTE_ORIGIN element specifies a network route origination point, as detailed in the NL_ROUTE_ORIGIN enumertaion in the MIB_IPFORWARD_ROW2 structure. For more information, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa814494(v=vs.85).aspx for the MIB_IPFORWARD_ROW2 structure and http://msdn.microsoft.com/en-us/library/windows/hardware/ff568764(v=vs.85).aspx for the NL_ROUTE_ORIGIN enumeration. + + + + + + + + + NLRouteOriginType specifies Windows-centric network route origination values via a union of the RouteOriginEnum type and the atomic xs:string type. Its base type is the CybOX BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The NLRouteOriginEnum type is a enumeration of network route origination points, as detailed in the NL_ROUTE_ORIGIN enumertaion in the MIB_IPFORWARD_ROW2 structure. For more information, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa814494(v=vs.85).aspx for the MIB_IPFORWARD_ROW2 structure and http://msdn.microsoft.com/en-us/library/windows/hardware/ff568764(v=vs.85).aspx for the NL_ROUTE_ORIGIN enumeration. + + + + + Specifies that the origin was determined as a result of manual configuration. + + + + + Specifies that the route is well-known. + + + + + Specifies that the origin was determined as a result of DHCP configuration. + + + + + Specifies that the origin was determined as a result of router advertisement. + + + + + Specifies that the origin was determined as a result of 6to4 tunneling. + + + + + + + NLRouteProtocolType specifies Windows-centric network routing protocol values via a union of the NLRouteProtocolEnum type and the atomic xs:string type. Its base type is the CybOX BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The NLRouteProtocolEnum type is a enumeration of network routing protocols, as detailed in the NL_ROUTE_PROTOCOL enumeration in the MIB_IPFORWARD_ROW2 structure. For more information, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa814494(v=vs.85).aspx for the MIB_IPFORWARD_ROW2 structure. + + + + + Specifies that the routing mechanism was not specified. + + + + + Specifies a local interface. + + + + + Specifies a static route. This value is used to identify route information for IP routing set through network management such as the Dynamic Host Configuration Protocol (DCHP), the Simple Network Management Protocol (SNMP), or by calls to the CreateIpForwardEntry2, DeleteIpForwardEntry2, or SetIpForwardEntry2 functions. + + + + + Specifies the result of an ICMP redirect. + + + + + Specifies the Exterior Gateway Protocol (EGP), a dynamic routing protocol. + + + + + Specifies the Gateway-to-Gateway Protocol (GGP), a dynamic routing protocol. + + + + + Specifies the hellospeak protocol, a dynamic routing protocol. This is a historical entry no longer in use and was an early routing protocol used by the original ARPANET routers that ran special software called the Fuzzball routing protocol, sometimes called Hellospeak, as described in RFC 891 and RFC 1305. For more information, see http://www.ietf.org/rfc/rfc891.txt and http://www.ietf.org/rfc/rfc1305.txt. + + + + + Specifies the Berkeley Routing Information Protocol (RIP) or RIP-II, a dynamic routing protocol. + + + + + Specifies the Intermediate System-to-Intermediate System (IS-IS) protocol, a dynamic routing protocol. The IS-IS protocol was developed for use in the Open Systems Interconnection (OSI) protocol suite. + + + + + Specifies the End System-to-Intermediate System (ES-IS) protocol, a dynamic routing protocol. The ES-IS protocol was developed for use in the Open Systems Interconnection (OSI) protocol suite. + + + + + Specifies the Cisco Interior Gateway Routing Protocol (IGRP), a dynamic routing protocol. + + + + + Specifies the Bolt, Beranek, and Newman (BBN) Interior Gateway Protocol (IGP) that used the Shortest Path First (SPF) algorithm. This was an early dynamic routing protocol. + + + + + Specifies the Open Shortest Path First (OSPF) protocol, a dynamic routing protocol. + + + + + Specifies the Border Gateway Protocol (BGP), a dynamic routing protocol. + + + + + Specifies a Windows specific entry added originally by a routing protocol, but which is now static. + + + + + Specifies a Windows specific entry added as a static route from the routing user interface or a routing command. + + + + + Specifies a Windows specific entry added as an static route from the routing user interface or a routing command, except these routes do not cause Dial On Demand (DOD). + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Network_Share_Object.xsd b/stix_validator/schema/cybox/objects/Win_Network_Share_Object.xsd new file mode 100755 index 0000000..25d3399 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Network_Share_Object.xsd @@ -0,0 +1,205 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Network_Share_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + he Windows_Network_Share object is intended to characterize Windows network shares. + + + + + he WindowsNetworkShareObjectType type is intended to characterize Windows network shares. + + + + + + + The Current_Uses field specifies the current number of uses of the network share. + + + + + The Local_Path field specifies the fully-qualified path on the local system to the network share. + + + + + The Max_Uses field specifies the maximum number of concurrent connections to the network share. + + + + + The Netname field specifies the network name of the network share. + + + + + The Type field specifies the type of the network share. + + + + + + + + + + SharedResourceType specifies Windows shared resource types via a union of the SharedResourceTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The SharedResourceTypeEnum type is an enumeration of Windows that specifies shared resource types for shared devices. These can be checked via the NetShareCheck function. See http://msdn.microsoft.com/en-us/library/windows/desktop/bb525385(v=vs.85).aspx for more information. + + + + + Specifies that the shared device is a disk drive. + + + + + Specifies that the shared device is a disk drive with special share reserved for interprocess communcation (IPC$) or remote administration of the server (ADMIN$). Can also refer to administrative shares such as C$, D$, E$, and so forth. For more information, see http://msdn.microsoft.com/en-us/library/windows/desktop/bb525391(v=vs.85).aspx. + + + + + Specifies that the shared device is a disk drive and serves as a temporary share. + + + + + Specifies that the shared device is a disk drive with special share reserved for interprocess communcation (IPC$) or remote administration of the server (ADMIN$) and serves a temporary share. Can also refer to administrative shares such as C$, D$, E$, and so forth. For more information, see http://msdn.microsoft.com/en-us/library/windows/desktop/bb525391(v=vs.85).aspx. + + + + + Specifies that the shared device is a print queue. + + + + + Specifies that the shared device is a disk drive with special share reserved for interprocess communcation (IPC$) or remote administration of the server (ADMIN$). Can also refer to administrative shares such as C$, D$, E$, and so forth. For more information, see http://msdn.microsoft.com/en-us/library/windows/desktop/bb525391(v=vs.85).aspx. + + + + + Specifies that the shared device is a print queue and serves as a temporary share. + + + + + Specifies that the shared device is a print queue with special share reserved for interprocess communcation (IPC$) or remote administration of the server (ADMIN$) and serves a temporary share. Can also refer to administrative shares such as C$, D$, E$, and so forth. For more information, see http://msdn.microsoft.com/en-us/library/windows/desktop/bb525391(v=vs.85).aspx. + + + + + Specifies that the shared device is a communications device. + + + + + Specifies that the shared device is a communications device with special share reserved for interprocess communcation (IPC$) or remote administration of the server (ADMIN$). Can also refer to administrative shares such as C$, D$, E$, and so forth. For more information, see http://msdn.microsoft.com/en-us/library/windows/desktop/bb525391(v=vs.85).aspx. + + + + + Specifies that the shared device is a communications device and serves as a temporary share. + + + + + Specifies that the shared device is a communications device with special share reserved for interprocess communcation (IPC$) or remote administration of the server (ADMIN$) and serves a temporary share. Can also refer to administrative shares such as C$, D$, E$, and so forth. For more information, see http://msdn.microsoft.com/en-us/library/windows/desktop/bb525391(v=vs.85).aspx. + + + + + Specifies that the shared device is an Interprocess Communication (IPC) device. + + + + + Specifies that the shared device is an Interprocess Communication (IPC) device with special share reserved for interprocess communcation (IPC$) or remote administration of the server (ADMIN$). Can also refer to administrative shares such as C$, D$, E$, and so forth. For more information, see http://msdn.microsoft.com/en-us/library/windows/desktop/bb525391(v=vs.85).aspx. + + + + + Specifies that the shared device is an Interprocess Communication (IPC) device and serves as a temporary share. + + + + + Specifies that the shared device is an Interprocess Communication (IPC) device with special share reserved for interprocess communcation (IPC$) or remote administration of the server (ADMIN$) and serves a temporary share. Can also refer to administrative shares such as C$, D$, E$, and so forth. For more information, see http://msdn.microsoft.com/en-us/library/windows/desktop/bb525391(v=vs.85).aspx. + + + + + + + The accesspermissions group specifies the various permissions for Windows network shares. + + + + The ACCESS_READ field specifies the permission to read data from a resource and, by default, to execute the resource. + + + + + The ACCESS_WRITE field specifies the permission to write data to the resource. + + + + + The ACCESS_CREATE field specifies the permission to create an instance of the resource (such as a file); data can be written to the resource as the resource is created. + + + + + The ACCESS_EXEC field specifies the permission to execute the resource. + + + + + The ACCESS_DELETE field specifies the permission to delete the resource. + + + + + The ACCESS_ATRIB field specifies the permission to modify the resource's attributes (such as the date and time when a file was last modified). + + + + + The ACCESS_PERM field specifies the permission to modify the permissions (read, write, create, execute, and delete) assigned to a resource for a user or application. + + + + + The ACCESS_ALL field specifies the permission to read, write, create, execute, and delete resources, and to modify their attributes and permissions. + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Pipe_Object.xsd b/stix_validator/schema/cybox/objects/Win_Pipe_Object.xsd new file mode 100755 index 0000000..a7d8939 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Pipe_Object.xsd @@ -0,0 +1,73 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Pipe_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + + Windows_Pipe object characterizes windows pipes. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365590(v=vs.85).aspx + + + + + The WindowsPipeObjectType type is intended to characterize Windows pipes. + + + + + + + The Default_Time_Out field specifies the default time-out value for the pipe, in milliseconds. + + + + + The Handle field specifies the open Windows handle to the pipe. It imports and uses the WindowsHandleObjectType from the CybOX Windows Handle Object. + + + + + The In_Buffer_Size field specifies the number of bytes to reserve for the input buffer of the pipe. + + + + + The Max_Instances field specifies the maximum number of instances that can be created for this pipe. + + + + + The Open_Mode field specifies the open mode used for the pipe. + + + + + The Out_Buffer_Size field specifies the number of bytes to reserve for the output buffer of the pipe. + + + + + The Pipe_Mode field specifies the mode used for the pipe. + + + + + The Security_Attributes field specifies the Windows security attributes for the pipe. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Prefetch_Object.xsd b/stix_validator/schema/cybox/objects/Win_Prefetch_Object.xsd new file mode 100755 index 0000000..6285865 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Prefetch_Object.xsd @@ -0,0 +1,113 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Prefetch_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + The Windows_Prefetch_Entry object is intended to characterize entries in the Windows prefetch files. Starting with Windows XP, prefetching was introduced to speed up application startup. The prefetch object draws upon the descriptions and XML sample at http://www.forensicswiki.org/wiki/Prefetch_XML + + + + + The WindowsPrefetchObjectType type is intended to characterize entries in the Windows prefetch files. Starting with Windows XP, prefetching was introduced to speed up application startup. The prefetch object draws upon the descriptions and XML sample at http://www.forensicswiki.org/wiki/Prefetch_XML + + + + + + + Name of the executable of the prefetch file. + + + + + An eight character hash of the location from which the application was run. + + + + + The number of times the prefetch application has executed. + + + + + Timestamp of when the prefetch application was first run. + + + + + Timestamp of when the prefetch application was last run. + + + + + The volume from which the prefetch application was run. If the applicatin was run from multiple volumes, there will be a separate prefetch file for each. + + + + + Files (e.g., DLLs and other support files) used by the application during startup. + + + + + Directories accessed by the prefetch application during starup. + + + + + + + + + The AccessedFileListType specifies a list of files accessed by a prefetch application. + + + + + Specifies the filename of the accessed file. + + + + + + + The AccessedDirectoryListType specifies a list of directories accessed by a prefetch application. + + + + + Specifies the pathname of the accessed directory. + + + + + + + VolumeType characterizes the volume information in the Windows prefetch file. + + + + + The volume that the prefetch application was run from. The only item in the prefecth file is the volume name. + + + + + The device that the prefetch application was run from. The only item in the prefetch file is the device serial number. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Process_Object.xsd b/stix_validator/schema/cybox/objects/Win_Process_Object.xsd new file mode 100755 index 0000000..5729a8b --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Process_Object.xsd @@ -0,0 +1,167 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Process_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + + Windows_Process object is intended to characterize Windows processes. + + + + + The WindowsProcessObjectType type is intended to characterize Windows processes. + + + + + + + The Handle_List field specifies a list of Windows Handles opened or used by the process. + + + + + The Priority field speciifes the current priority of the process in Windows. + + + + + The Section_List field specifies the memory sections used by the process. + + + + + The Security_ID field specifies the Security ID (SID) value assigned to the process. + + + + + The Startup_Info field specifies the STARTUP_INFO struct used by the process. + + + + + The Security_Type field specifies the type of Security ID (SID) assigned to the process. + + + + + The Window_Title field specifies the title of the main window of the process. + + + + + + The aslr_enabled field specifies whether Address Space Layout Randomization (ASLR) is enabled for the process. + + + + + The dep_enabled field specifies whether Data Execution Prevention (DEP) is enabled for the process. + + + + + + + + The MemorySectionListType type specifies a list of memory sections used by the process. + + + + + The Memory_Section field specifies a memory section used by the process. It imports and uses the MemoryObjectType from the CybOX Memory Object. + + + + + + + The StartupInfoType type encapsulates the information contained in the STARTUPINFO struct for the process. + + + + + The lpDesktop field specifies the name of the desktop, or the name of both the desktop and window station for this process. + + + + + The lpTitle field specifies the title displayed in the title bar if a new console window is created. + + + + + The dwX field specifies the x offset of the upper left corner of a window if a new window is created, in pixels. + + + + + The dwY field specifies the y offset of the upper left corner of a window if a new window is created, in pixels. + + + + + The dwXSize field specifies the width of the window if a new window is created, in pixels. + + + + + The dwYSize field specifies the height of the window if a new window is created, in pixels. + + + + + The dwXCountChars field specifies the screen buffer width, in character columns. + + + + + The dwYCountChars field specifies the screen buffer height, in character rows. + + + + + The dwFillAttribute field specifies the initial text and background colors if a new console window is created in a console application. + + + + + The dwFlags field specifies a bitfield that determines whether certain STARTUPINFO members are used when the process creates a window. + + + + + The wShowWindow field specifies STARTF_USESHOWWINDOW, this member can be any of the values that can be specified in the nCmdShow parameter for the ShowWindow function, except for SW_SHOWDEFAULT. + + + + + The hStdInput field specifies the standard input handle for the process. + + + + + The hStdOutput field specifies the standard output handle for the process. + + + + + The hStdError field specifies the standard error handle for the process. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Registry_Key_Object.xsd b/stix_validator/schema/cybox/objects/Win_Registry_Key_Object.xsd new file mode 100755 index 0000000..0021d64 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Registry_Key_Object.xsd @@ -0,0 +1,290 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Registry_Key_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + Windows_Registry_Key object characterizes windows registry objects, including Keys and Key/Value pairs. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724871(v=vs.85).aspx + + + + + The WindowsRegistryObjectType type is intended to characterize Windows registry objects, including Keys and Key/Value pairs. + + + + + + + The Key field specifies the full key to the Windows registry object, not including the hive. + + + + + The Hive field specifies the Windows registry hive to which the registry object belongs to. + + + + + The Number_Values field specifies the number of values found in the registry key. + + + + + The Values field specifies the values (with their name/data pairs) held within the registry key. + + + + + The Modified_Time field specifies the last date/time that the registry object was modified. + + + + + The Creator_Username field specifies the name of the user who created the registry object. + + + + + The Handle_List field specifies a list of open Handles for this registry object. + + + + + The Number_Subkeys field specifies the number of subkeys contained under the registry key. + + + + + The Subkeys field specifies the set of subkeys contained under the registry key. + + + + + The Byte_Runs field contains a list of byte runs from the raw registry. + + + + + + + + + The RegistryValueType type is intended to characterize Windows registry Value name/data pairs. + + + + + The Name field specifies the name of the registry value. + + + + + The Data field specifies the data contained in the registry value. + + + + + The Datatype field specifies the registry (REG_*) datatype used in the registry value. + + + + + The Byte_Runs field contains a list of byte runs from the raw registry key entry. + + + + + + + Registry_Datatype specifies Windows registry datatypes via a union of the RegistryDataTypesEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + RegistryHiveType specifies Windows registry hive types via a union of the RegistryHiveEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The RegistryDataTypesEnum type is an enumeration of Windows registry datatypes (REG_*). See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724884(v=vs.85).aspx See also: http://pubs.logicalexpressions.com/Pub0009/LPMArticle.asp?ID=361 + + + + + No defined value type. + + + + + A null-terminated string. This will be either a Unicode or an ANSI string, depending on whether you use the Unicode or ANSI functions. + + + + + A null-terminated string that contains unexpanded references to environment variables (for example, "%PATH%"). It will be a Unicode or ANSI string depending on whether you use the Unicode or ANSI functions. + + + + + Binary data in any form. + + + + + A 32-bit number. + + + + + A 32-bit number in big-endian format. Some UNIX systems support big-endian architectures. + + + + + A null-terminated Unicode string that contains the target path of a symbolic link. + + + + + A sequence of null-terminated strings, terminated by an empty string (\0). + + + + + A series of nested arrays designed to store a resource list used by a hardware device driver or one of the physical devices it controls. This data is detected and written into the ResourceMap tree by the system and is displayed in Registry Editor in hexadecimal format as a Binary Value. + + + + + A series of nested arrays designed to store a resource list used by a physical hardware device. This data is detected and written into the HardwareDescription tree by the system and is displayed in Registry Editor in hexadecimal format as a Binary Value. + + + + + Device driver list of hardware resource requirements in Resource Map tree. See http://www.mdgx.com/reg.htm + + + + + A 64-bit number. + + + + + Specifies an invalid key. + + + + + + + The RegistryHiveEnum type is an enumeration of Windows registry hives (HKEY_*). See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724836(v=vs.85).aspx + + + + + Registry entries subordinate to this key define types (or classes) of documents and the properties associated with those types. Shell and COM applications use the information stored under this key. + + + + + Contains information about the current hardware profile of the local computer system. The information under HKEY_CURRENT_CONFIG describes only the differences between the current hardware configuration and the standard configuration. + + + + + Registry entries subordinate to this key define the preferences of the current user. These preferences include the settings of environment variables, data about program groups, colors, printers, network connections, and application preferences. This key makes it easier to establish the current user's settings; the key maps to the current user's branch in HKEY_USERS. + + + + + Registry entries subordinate to this key define the physical state of the computer, including data about the bus type, system memory, and installed hardware and software. + + + + + Registry entries subordinate to this key define the default user configuration for new users on the local computer and the user configuration for the current user. + + + + + Registry entries subordinate to this key define preferences of the current user that are local to the machine. These entries are not included in the per-user registry portion of a roaming user profile. + + + + + Registry entries subordinate to this key allow you to access performance data. The data is not actually stored in the registry; the registry functions cause the system to collect the data from its source. + + + + + Registry entries subordinate to this key reference the text strings that describe counters in the local language of the area in which the computer system is running. These entries are not available to Regedit.exe and Regedt32.exe. + + + + + Registry entries subordinate to this key reference the text strings that describe counters in US English. These entries are not available to Regedit.exe and Regedt32.exe. + + + + + + + The RegistryValuesType type specifies the values (with their name/data pairs) held within the registry key. + + + + + The Value field specifies the value (with name/data pair) held within the registry key. + + + + + + + The RegistrySubkeysType specifies the set of subkeys contained under the registry key. + + + + + The Subkey field specifies a single subkey contained under the registry key. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Semaphore_Object.xsd b/stix_validator/schema/cybox/objects/Win_Semaphore_Object.xsd new file mode 100755 index 0000000..16578f6 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Semaphore_Object.xsd @@ -0,0 +1,42 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Semaphore_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + Windows_Semaphore object is intended to characterize Windows Semaphore (synchronization) objects. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms685129(v=vs.85).aspx + + + + + The WindowsSemaphoreObjectType is intended to characterize Windows semaphore (synchronization) objects. + + + + + + + The Handle field specifies the open Windows handle to the semaphore. It imports and uses the WindowsHandleObjectType from the CybOX Windows Handle Object. + + + + + The Security_Attributes field specifies the Windows security attributes for the semaphore. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Service_Object.xsd b/stix_validator/schema/cybox/objects/Win_Service_Object.xsd new file mode 100755 index 0000000..23de5fc --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Service_Object.xsd @@ -0,0 +1,287 @@ + + + + Change to This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Service_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + Windows_Service object is intended to characterize Windows services. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms685141(v=vs.85).aspx + + + + + The WindowsServiceObjectType type is intended to characterize Windows services. + + + + + + + A list of description items for this service. + + + + + The Display_Name field specifies the displayed name of the service in Windows GUI controls. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms683228(v=vs.85).aspx + + + + + The Group_Name field specifies the name of the load ordering group of which this service is a member. + + + + + The Name field specifies the name of the service. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms683229(v=vs.85).aspx + + + + + The Service_DLL field specifies name of the DLL instantiated in the service. + + + + + The Certificate Authority (CA) that issued the certificate used to sign the service DLL. + + + + + The subject of the certifcate (the entity being authenticated). + + + + + Hashes for the Service DLL file. + + + + + The Service_DLL_Signature_Description field provides a description of the digital signature for the service DLL. + + + + + The Startup_Command_Line field specifies the full command line used to start the service. + + + + + Service start options. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms682450(v=vs.85).aspx + + + + + Status information for a service. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms685996(v=vs.85).aspx + + + + + The Type field specifies the type of the service. + + + + + The Started_As field specifies the name of the account under which the service was started. + + + + + + Indicates whether or not the DLL is signed. + + + + + Indicates whether or not the DLL's signature was verified. + + + + + + + + A collection of service descriptions. + + + + + A description of the service. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms685156(v=vs.85).aspx + + + + + + + ServiceModeType specifies Windows service modes via a union of the ServiceModeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + ServiceModeType specifies Windows service states via a union of the ServiceStatusEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + ServiceType specifies Windows service types via a union of the ServiceTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The ServiceModeEnum type is an enumeration of service modes. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682450(v=vs.85).aspx + + + + + + + A service started automatically by the service control manager during system startup. + + + + + A device driver started by the system loader. This value is valid only for driver services. + + + + + A service started by the service control manager when a process calls the StartService function. + + + + + A service that cannot be started. Attempts to start the service result in the error code ERROR_SERVICE_DISABLED. + + + + + A device driver started by the IoInitSystem function. This value is valid only for driver services. + + + + + + + + + The ServiceStatusEnum type is an enumeration of potential service states. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms685996(v=vs.85).aspx + + + + + + + The service continue is pending. + + + + + The service pause is pending. + + + + + The service is paused. + + + + + The service is running. + + + + + The service is starting. + + + + + The service is stopping. + + + + + The service is not running. + + + + + + + + + The ServiceTypeEnum type is an enumeration of service types. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms685996(v=vs.85).aspx + + + + + + + The service is a device driver. + + + + + The service is a file system driver. + + + + + The service runs in its own process. + + + + + The service shares a process with other services. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_System_Object.xsd b/stix_validator/schema/cybox/objects/Win_System_Object.xsd new file mode 100755 index 0000000..f347895 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_System_Object.xsd @@ -0,0 +1,126 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_System_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + + Windows_System object is intended to characterize Windows systems. + + + + + The WindowsSystemObjectType type is intended to characterize Windows systems. + + + + + + + The domain that the system belongs to. + + + + + A list of global flags. See also: http://msdn.microsoft.com/en-us/library/windows/hardware/ff549557(v=vs.85).aspx + + + + + The NetBIOS_Name field specifies the NetBIOS (Network Basic Input/Output System) name of the Windows system. This is not the same as the host name. + + + + + The Open_Handle_List field specifies the list of open handles for the Windows system. + + + + + The Product ID. See also: http://support.microsoft.com/gp/pidwin + + + + + The ProductName of the current installation of Windows. This is typically found in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion!ProductName + + + + + The organization that this copy of Windows is registered to. + + + + + The person or organization that is the registered owner of this copy of Windows. + + + + + The Windows_Directory field specifies the fully-qualified path to the Windows install directory. + + + + + The Windows_System_Directory field specifies the fully-qualified path to the Windows system directory. + + + + + The Windows_Temp_Directory field specifies the fully-qualified path to the Windows temporary files directory. + + + + + + + + + The GlobalFlagListType type is a listing of all Windows global flags. + + + + + This characterizes Windows global flags. See also: http://msdn.microsoft.com/en-us/library/windows/hardware/ff549557(v=vs.85).aspx + + + + + + + The GlobalFlagType type is intended to characterize Windows global flags. + + + + + The abbreviation of a global flag. See also: http://msdn.microsoft.com/en-us/library/windows/hardware/ff549646(v=vs.85).aspx + + + + + The destination of a global flag. See also: http://msdn.microsoft.com/en-us/library/windows/hardware/ff549646(v=vs.85).aspx + + + + + The hexadecimal value of a global flag. See also: http://msdn.microsoft.com/en-us/library/windows/hardware/ff549646(v=vs.85).aspx + + + + + The symbolic name of a global flag. See also: http://msdn.microsoft.com/en-us/library/windows/hardware/ff549646(v=vs.85).aspx + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_System_Restore_Object.xsd b/stix_validator/schema/cybox/objects/Win_System_Restore_Object.xsd new file mode 100755 index 0000000..505d943 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_System_Restore_Object.xsd @@ -0,0 +1,199 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_System_Restore_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + Windows_System_Restore_Entry object is intended to characterize Windows system restore points. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/dd408121(v=vs.85).aspx + + + + + The WindowsSystemRestoreObjectType is intended to characterize Windows system restore points. + + + + + + + The description of this restore point + + + + + The full path to the restore point + + + + + The name associated with this restore point. + + + + + The type of restore point. (ex: "Checkpoint") + + + + + The SID associated with a restore point change log event. This usually appears when the event flag includes "ACL Info". + + + + + The username associated with a restore point change log event. It usually appears when the event flag includes "ACL Info" + + + + + The backup file name associated with a particular restore point change log event + + + + + The change event associated with this restore point object (ex: "System Checkpoint", "Software Installation", etc.) + + + + + The flags associated with a restore point change log entry (ex: "ACL Info, "Short Name", etc.) + + + + + The change log sequence number associated with this restore point object + + + + + The changelog entry type associated with this restore point object. + + + + + The changelog file associated with the restore point + + + + + The created date of the system restore point. + + + + + Attributes of the file associated with this restore point object (ex: "Directory") + + + + + The new filename of the file associated with this restore point object. + + + + + The original filename associated with this restore point change log event + + + + + The original Short filename (SFN) of the file associated with this restore point object + + + + + The process name associated with this restore point object. + + + + + The registry hives associated with this restore point + + + + + + + + + + + + + + ChangeLogEntryTypeType types, via a union of the ChangeLogEntryTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The change types found in a Restore Point changelog> + + + + + Represents a changelog entry descriptor for updating an ACL. (0x00000001) + + + + + Represents a changelog entry descriptor for updating attributes. (0x00000002) + + + + + Represents a changelog entry descriptor for deleting a file. (0x00000004) + + + + + Represents a changelog entry descriptor for creating a file. (0x00000010) + + + + + Represents a changelog entry descriptor for renaming a file. (0x00000020) + + + + + Represents a changelog entry descriptor for creating a directory. (0x00000040) + + + + + Represents a changelog entry descriptor for renaming a directory. (0x00000080) + + + + + Represents a changelog entry descriptor for deleting a directory. (0x00000100) + + + + + Related to filesystem attachment points. (0x00000200) + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Task_Object.xsd b/stix_validator/schema/cybox/objects/Win_Task_Object.xsd new file mode 100755 index 0000000..be82a93 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Task_Object.xsd @@ -0,0 +1,755 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Task_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Windows_Task object is intended to characterize Windows task scheduler tasks. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381311(v=vs.85).aspx + + + + + The WindowsTaskObjectType type is intended to characterize Windows task scheduler tasks. See Also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381311(v=vs.85).aspx + + + + + + + The Status field specifies the current status of the scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381263(v=vs.85).aspx + + + + + The Priority field specifies the priority of the scheduled task. This can either be a free-form string or one the values in the TaskPriorityEnum enumeration. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381876(v=vs.85).aspx + + + + + The Name field specifies the image name for the task. + + + + + The Application_Name specifies the application name associated with the task. + + + + + The Parameters field specifies the command line parameters used to launch the scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381875(v=vs.85).aspx + + + + + The Flags field specifies any flags that modify the behavior of the scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381248(v=vs.85).aspx + + + + + The Account_Name field specifies the name of the account used to run the scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381228(v=vs.85).aspx + + + + + The Account_Run_Level field specifies the permission level of the account that the task will be run at. + + + + + The Account_Logon_Type field specifies the security logon method required to run the tasks associated with the account. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa383013(v=vs.85).aspx + + + + + The Creator field specifies the name of the creator of the scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381235(v=vs.85).aspx + + + + + The Creation_Date field specifies the date and time that the task was registered. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa382623(v=vs.85).aspx + + + + + The Most_Recent_Run_Time field specifies the most recent run date/time of this scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381254(v=vs.85).aspx + + + + + The Exit_Code field specifies the last exit code of the scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381245(v=vs.85).aspx + + + + + The Max_Run_Time field specifies the maximum run time of the scheduled task before terminating, in milliseconds. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381874(v=vs.85).aspx + + + + + The Next_Run_Time field specifies the next run date/time of the scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381257(v=vs.85).aspx + + + + + The Action_List field specifies a list of actions to be performed by the scheduled task. + + + + + The Trigger_List field specifies a set of triggers used by the scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa383264(v=vs.85).aspx + + + + + The Comment field specifies a comment for the scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381232(v=vs.85).aspx + + + + + The Working_Directory field specifies the working directory for the scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381878(v=vs.85).aspx + + + + + The Work_Item_Data field specifies application defined data associated with the scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381271(v=vs.85).aspx + + + + + + + + + The TriggerListType type specifies a set of triggers associated with the scheduled task. + + + + + A trigger associated with this scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381264(v=vs.85).aspx + + + + + + + The TriggerType type characterizes task triggers. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa383868(v=vs.85).aspx + + + + + The Trigger_Begin_Element specifies the date/time that the trigger is activated. + + + + + The Trigger_Delay field specifies the delay that takes place between when the task is registered and when the task is started. + + + + + The Trigger_End field specifies the date/time that the trigger is deactivated. + + + + + The Trigger_Frequency field specifies the frequency at which the trigger repeats. + + + + + The maximum amount of time that the task launched by the trigger is allowed to run. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa383868(v=vs.85).aspx + + + + + The Trigger_Session_Change_Type field specifies the type of Terminal Server session change that would trigger a task launch. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381298(v=vs.85).aspx + + + + + The Trigger_Type specifies the type of the task trigger. + + + + + + The enabled field specifies whether the trigger is enabled. + + + + + + The TaskActionListType type specifies a list of task actions. + + + + + The work items performed by a task are called actions. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa383549(v=vs.85).aspx + + + + + + + The TaskActionType type characterizes scheduled task actions. + + + + + The Action_Type field specifies the type of the action. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380596(v=vs.85).aspx + + + + + The Action_ID field specifies the user-defined identifier for the action. This identifier is used by the Task Scheduler for logging purposes. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380590(v=vs.85).aspx + + + + + The IEmail_Action field specifies an action that sends an e-mail, which in this context refers to actual email message sent. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380693(v=vs.85).aspx + + + + + The IComHandlerAction field specifies an action that fires a handler. + + + + + The IExecAction field specifies an action that executes a command-line operation. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380715(v=vs.85).aspx + + + + + The IShowMessageAction field specifies an action that shows a message box when a task is activated. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381302(v=vs.85).aspx + + + + + + + The TaskActionTypeType characterizes the specific types of task actions. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The IComHandlerActionType type characterizes IComHandler actions. + + + + + The COM_Data field specifies the data associated with the COM handler. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380613(v=vs.85).aspx + + + + + The COM_Class_ID field specifies the ID of the COM action. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380613(v=vs.85).aspx + + + + + + + The IExecActionType type characterizes IExec actions. + + + + + The Exec_Arguments field specifies the arguments associated with the command-line operation launched by the action. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380715(v=vs.85).aspx + + + + + The Exec_Program_Path field specifies the path to the executable file launched by the action. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380715(v=vs.85).aspx + + + + + The Exec_Working_Directory field specifies the directory that contains either the executable file or the files that are used by the executable file launched by the action. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380715(v=vs.85).aspx + + + + + The Exec_Program_Element specifies the hashes of the executable file launched by the action. + + + + + + + The IShowMessageActionType type characterizes IShowMessage actions. + + + + + The Show_Message_Body field specifies the message text that is displayed in the body of the message box by the action. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381302(v=vs.85).aspx + + + + + The Show_Message_Title field specifies the title of the message box shown by the action. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381302(v=vs.85).aspx + + + + + + + The TaskFlagType type specifies Windows Task flag types via a union of the TaskFlagEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The TaskPriorityType type specifies Windows Task priority types via a union of the TaskPriorityEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The TaskTriggerFrequencyType type specifies Windows Task trigger frequency types via a union of the TriggerFrequencyEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The TaskTriggerType type specifies Windows Task trigger types via a union of the TriggerTypeEnum enumeration and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The TaskStatusType type specifies Windows Task states via a union of the TaskStatusEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + An enumeration of action types. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380596(v=vs.85).aspx + + + + + + This action performs a command-line operation. For example, the action could run a script, launch an executable, or, if the name of a document is provided, find its associated application and launch the application with the document. + + + + + This action fires a handler. + + + + + This action sends an e-mail. + + + + + This action shows a message box. + + + + + + + The TaskFlagEnum enumeration specifies the run flags for a task scheduler task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381283(v=vs.85).aspx See Also: http://msdn.microsoft.com/en-us/library/microsoft.office.excel.server.addins.computecluster.taskscheduler.taskflags(v=office.12).aspx + + + + + + + + This flag is used when converting Windows NT AT service jobs into work items. The Windows NT AT service job refers to At.exe, the Windows NT command-line utility used for creating jobs for the Windows NT Schedule service. The Task Scheduler service replaces the Schedule service and is backwards compatible with it. The conversion occurs when the Task Scheduler is installed on Windows NT/Windows 2000— for example, if you install Internet Explorer 4.0, or upgrade to Windows 2000. During the setup process, the Task Scheduler installation code searches the registry for jobs created for the AT service and creates work items that will accomplish the same operation. For such converted jobs, the interactive flag is set if the work item is intended to be displayed to the user. When this flag is not set, no work items are displayed in the Tasks folder, and no user interface associated with the work item is presented to the user when the work item is executed. + + + + + The work item will be deleted when there are no more scheduled run times. + + + + + The work item is disabled. This is useful to temporarily prevent a work item from running at the scheduled time(s). + + + + + The work item created will be hidden. + + + + + The work item runs only if the user specified in IScheduledWorkItem::SetAccountInformation is logged on interactively. This flag has no effect on the work items that are set to run in the local account. + + + + + The work item begins only if the computer is not in use at the scheduled start time. + + + + + The work item causes the system to be resumed, or awakened, if the system is running on battery power. This flag is supported only on systems that support resume timers. + + + + + The work item terminates if the computer makes an idle to non-idle transition while the work item is running. The computer is not considered idle until the IdleWait triggers' time elapses with no user input. For information regarding idle triggers, see Idle Trigger. + + + + + The work item starts again if the computer makes a non-idle to idle transition before all the work item's task_triggers elapse. (Use this flag in conjunction with TASK_FLAG_KILL_ON_IDLE_END.) + + + + + The work item does not start if its target computer is running on battery power. + + + + + The work item ends, and the associated application quits if the work item's target computer switches to battery power. + + + + + The work item runs only if there is currently a valid Internet connection. + + + + + + + + + The TaskPriorityEnum enumeration specifies the priority levels of task scheduler tasks. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa383512(v=vs.85).aspx + + + + + A priority class of high (1) + + + + + A priority class of normal (4-6) + + + + + A priority class of idle (9-10) + + + + + A priority class of realtime (0) + + + + + A priority class of above normal (2-3) + + + + + A priority class of below normal (7-8) + + + + + + + The TriggerFrequencyEnum enumeration defines the frequency types that a trigger may use. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa383620(v=vs.85).aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/aa383987(v=vs.85).aspx + + + + + Trigger is set to run the task a single time. + + + + + Trigger is set to run the task if the system remains idle for the amount of time specified by the idle wait time of the task. + + + + + Trigger is set to run the task at system startup. + + + + + Trigger is set to run the task when a user logs on. + + + + + Trigger is set to run the task on a daily interval. + + + + + Trigger is set to run the work item on specific days of a specific week of a specific month. + + + + + Trigger is set to run the task on a specific day(s) of the month. + + + + + Trigger is set to run the task on specific days, weeks, and months. + + + + + + + The TriggerFrequencyEnum enumeration defines the types of triggers associated with a task. + + + + + Triggers the task when a specific system event occurs. + + + + + Triggers the task at a specific date and time. + + + + + Triggers the task when the computer enters an idle state. + + + + + Triggers the task when the task is registered or updated. + + + + + Triggers the task when the system is booted. + + + + + Triggers the task when a user logs on. + + + + + Triggers the task when a Terminal Server session changes state. + + + + + + + The TaskStatusEnum enumeration specifies the possible statuses of a scheduled task. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa383604(v=vs.85).aspx See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381263(v=vs.85).aspx See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa381833(v=vs.85).aspx See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa383617(v=vs.85).aspx + + + + + The task is ready to run at its next scheduled time. + + + + + The task is currently running. + + + + + One or more of the properties that are needed to run this task on a schedule have not been set. + + + + + The Task Scheduler service is not running. + + + + + The task has been configured with an unsupported combination of account settings and run time options. + + + + + The task object version is either unsupported or invalid. + + + + + Task Scheduler security services are available only on Windows NT. + + + + + Corruption was detected in the Task Scheduler security database; the database has been reset. + + + + + Unable to establish existence of the account specified. + + + + + No account information could be found in the Task Scheduler security database for the task indicated. + + + + + The object is either an invalid task object or is not a task object. + + + + + The task object could not be opened. + + + + + The Task Scheduler service is not installed on this computer. + + + + + There is no running instance of the task. + + + + + One or more of the properties required to run this task have not been set. + + + + + A task's trigger is not found. + + + + + Event triggers do not have set run times. + + + + + Either the task has no triggers or the existing triggers are disabled or not set. + + + + + The last run of the task was terminated by the user. + + + + + There are no more runs scheduled for this task. + + + + + The task has not been run. This value is returned whenever the task has not been run, even if the task is ready to be run at the next scheduled time or the task is a recurring task. + + + + + The task will not run at the scheduled times because it has been disabled. + + + + + The state of the task is unknown. + + + + + Instances of the task are queued. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Thread_Object.xsd b/stix_validator/schema/cybox/objects/Win_Thread_Object.xsd new file mode 100755 index 0000000..880ba5d --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Thread_Object.xsd @@ -0,0 +1,146 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Thread_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + The Windows_Threat object is intended to characterize Windows process threads. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684852(v=vs.85).aspx + + + + + The Windows_ThreadObjectType is intended to characterize Windows process threads. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684852(v=vs.85).aspx + + + + + + + Represents the identifier of this thread. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms683183(v=vs.85).aspx + + + + + Handle represents the handle of a specific thread. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682453(v=vs.85).aspx + + + + + Running Status represents the running state that the thread is in. + + + + + The Context field specifies the thread context structure, which contains processor-specific register data. + + + + + Represents the priority of the thread. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100(v=vs.85).aspx + + + + + The Creation flags field represents the creation flags that a thread may be launched with. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684863(v=vs.85).aspx + + + + + Creation time represents the creation time of the thread. + + + + + Start address represents the start address of this thread, representing the memory address where this thread should start. See Also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682453(v=vs.85).aspx + + + + + + Security attributes represents the security attributes for the thread. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/aa379560(v=vs.85).aspx + + + + + Represents the stack size of the thread. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms686774(v=vs.85).aspx + + + + + + + + + ThreadRunningStatusType specifies Windows thread running states via a union of the ThreadRunningStatusEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + Thread running status enumerates the various states that a thread may be in before, during, or after execution. See http://msdn.microsoft.com/en-us/library/system.diagnostics.threadstate(v=vs.110).aspx + + + + + A state that indicates the thread has been initialized, but has not yet started. + + + + + A state that indicates the thread is waiting to use a processor because no processor is free. The thread is preapared to run on the next available processor. + + + + + A state that indicates the thread is currently using a prcoessor. + + + + + A state that indicates the thread is about to use a processor. Only one thread can be in this state at a time. + + + + + A state that indicates the thread has finished executing and has exited. + + + + + A state that indicates the thread is not ready to use the processor because it is waiting for a peripheral operation to complete or a resource to become free. When the thread is ready, it will be rescheduled. + + + + + A state that indicates the thread is waiting for a resource, other than the processor, before it can execute. + + + + + The thread of the thread is unknown. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_User_Account_Object.xsd b/stix_validator/schema/cybox/objects/Win_User_Account_Object.xsd new file mode 100755 index 0000000..0b64165 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_User_Account_Object.xsd @@ -0,0 +1,73 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_User_Account_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + Windows_User_Account object is intended to characterize Windows user accounts. + + + + + The WinUserAccountObjectType type is intended to characterize Windows user accounts. + + + + + + + Security ID represents the Security ID (SID) of a windows user. + + + + + Security Type represents the type of the Security ID (SID). + + + + + + + + + Windows Group represents a single windows group. + + + + + + + Identifies the name of the windows group. + + + + + + + + + Windows Privilege represents a single privilege that a user may have within Windows. + + + + + + + User Right represents one right that a user may have. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Volume_Object.xsd b/stix_validator/schema/cybox/objects/Win_Volume_Object.xsd new file mode 100755 index 0000000..496ce0d --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Volume_Object.xsd @@ -0,0 +1,161 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Volume_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + Windows_Volume object is intended to characterize Windows disk volumes. This object is roughly based on the Windows Volume Object: http://msdn.microsoft.com/en-us/library/windows/desktop/aa383970(v=vs.85).aspx. + + + + + The WindowsVolumeObjectType type is intended to characterize Windows disk volumes. + + + + + + + Represents the attributes of this windows volume object. + + + + + Represents the drive letter of this windows volume object. + + + + + Represents the drive type of this windows volume object. + + + + + + + + + A list of attributes describing this windows volume. + + + + + Each attribute field represents a single attribute in the windows volume attribute list. + + + + + + + WindowsDriveType specifies Windows drive types via a union of the WindowsDriveTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + WindowsVolumeAttributeType specifies Windows volume attributes via a union of the WindowsVolumeAttributeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + This enumeration contains possible drive types, as enumerated by the WINAPI GetDriveType function: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364939(v=vs.85).aspx + + + + + The drive type cannot be determined. + + + + + The root path is invalid; for example, there is no volume mounted at the specified path. + + + + + The drive has removable media; for example, a floppy drive, thumb drive, or flash card reader. + + + + + The drive has fixed media; for example, a hard disk drive or flash drive. + + + + + The drive is a remote (network) drive. + + + + + The drive is a CD-ROM drive. + + + + + The drive is a RAM disk. + + + + + + + This enumeration is a list of attributes that may be returned by the diskpart attributes command: http://technet.microsoft.com/en-us/library/cc766465(v=ws.10).aspx + + + + + Specifies that the volume is read-only. + + + + + Specifies that the volume is hidden. + + + + + Specifies that the volume does not receive a drive letter by default. + + + + + Specifies that the volume is a shadow copy volume. + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/Win_Waitable_Timer_Object.xsd b/stix_validator/schema/cybox/objects/Win_Waitable_Timer_Object.xsd new file mode 100755 index 0000000..e4bc3f2 --- /dev/null +++ b/stix_validator/schema/cybox/objects/Win_Waitable_Timer_Object.xsd @@ -0,0 +1,90 @@ + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + Win_Waitable_Timer_Object + 2.0 + 02/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + + Windows_Waitable_Timer object is intended to characterize Windows waitable timer (synchronization) objects. + + + + + The WindowsWaitableTimerObjectType is intended to characterize Windows waitable timer (synchronization) objects. + + + + + + + The Handle field specifies the handle to the Windows waitable timer object. It imports and uses the WindowsHandleObjectType type from the CybOX Windows Handle object. + + + + + The Name field specifies the name of the Windows waitable timer object. + + + + + The Security_Attributes field specifies the security attributes for the Windows waitable timer object. + + + + + The Type property specifies the type of the windows waitable timer object. + + + + + + + + + WaitableTimerType specifies Windows waitable timer types via a union of the WaitableTimerTypeEnum type and the atomic xs:string type. Its base type is the CybOX Core BaseObjectPropertyType, for permitting complex (i.e. regular-expression based) specifications. + + + + + + + + + This attribute is optional and specifies the expected type for the value of the specified property. + + + + + + + + The WaitableTimerTypeEnum type is an enumeration of Windows waitable timer types. + + + + + A timer whose state remains signaled until SetWaitableTimer is called to establish a new due time. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687012(v=vs.85).aspx + + + + + A timer whose state remains signaled until a thread completes a wait operation on the timer object. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687012(v=vs.85).aspx + + + + + A timer that is reactivated each time the specified period expires, until the timer is reset or canceled. A periodic timer is either a periodic manual-reset timer or a periodic synchronization timer. See also: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687012(v=vs.85).aspx + + + + + \ No newline at end of file diff --git a/stix_validator/schema/cybox/objects/X509_Certificate_Object.xsd b/stix_validator/schema/cybox/objects/X509_Certificate_Object.xsd new file mode 100755 index 0000000..6600566 --- /dev/null +++ b/stix_validator/schema/cybox/objects/X509_Certificate_Object.xsd @@ -0,0 +1,270 @@ + + + + + This schema was originally developed by The MITRE Corporation. The CybOX XML Schema implementation is maintained by The MITRE Corporation and developed by the open CybOX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the CybOX website at http://cybox.mitre.org. + + X509_Certificate_Object + 2.0 + 03/11/2013 9:00:00 AM + The following specifies the fields and types that compose this defined CybOX Object type. Each defined object is an extension of the abstract ObjectPropertiesType, defined in CybOX Common. For more information on this extension mechanism, please see the CybOX Specification. This document is intended for developers and assumes some familiarity with XML. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the CybOX License located at http://cybox.mitre.org/about/termsofuse.html. See the CybOX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the CybOX Schema, this license header must be included. + + + + + + X509_Certificate object represents a public key certificate for use in a public key infrastructure. + + + + + The X509CertificateObjectType type is intended to characterize X.509 certificates. + + + + + + + Certificate represents the contents of an X.509 certificate, including items such as issuer, subject, and others. + + + + + Certificate Signature contains the signature and signature algorithm of this X.509 certificate. + + + + + + + + + The X509CertificateType type represents the contents of an X.509 certificate, including items such as issuer, subject, and others. + + + + + Version describes the version of the encoded certificate. + + + + + The serial number is a unique identifier for each X.509 certificate issued by a specific Certificate Authority. + + + + + The signature algorithm is the algorithm used to sign the X.509 certificate. + + + + + The issuer is the Certificate Authority who issued the X.509 certificate. + + + + + Validity is the time interval during which the issuer warrants that it will maintain information about the status of the certificate. + + + + + The subject identifies the entity associated with the public key stored in the subject public key field of the X.509 certificate. + + + + + The Subject Public Key is used to carry the public key and identify the algorithm with which the key is used. + + + + + The Standard_Extensions field captures standard X509 V3 extensions that may be specified in the certificate. + + + + + The Non_Standard_Extensions field captures non-standard X509 extensions that may be specified in the certificate. + + + + + + + The X509CertificateSignatureType contains the signature and signature algorithm of this X.509 certificate. + + + + + Signature Algorithm contains the algorithm identifier for the algorithm used by the Certificate Authority to compute the signature. + + + + + Signature contains a digital signature computed upon this X.509 certificate. + + + + + + + The SubjectPublicKeyType is used to carry the public key and identify the algorithm with which the key is used. + + + + + Public Key Algorithm is the algorithm with which to encrypt data being sent to the subject. + + + + + RSA Public Key is the public key contained in this X.509 certificate. + + + + + + + The ValidityType type is the time interval during which the issuer warrants that it will maintain information about the status of the certificate. + + + + + Not before is the date on which the certificate validity period begins. + + + + + Not after is the date on which the certificate validity period ends. + + + + + + + The RSAPublicKeyType captures details of RSA public keys. + + + + + Modulus is the modulus portion of a public key. + + + + + Exponent is the exponent portion of a public key. + + + + + + + The X509V3ExtensionsType captures the standard X509 V3 Extensions that may be used in X509 certificates. Based on RFC 3280, "Standard Extensions": http://www.ietf.org/rfc/rfc3280.txt + + + + + The Basic_Constraints field captures a multi-valued extension which indicates whether a certificate is a CA certificate. The first (mandatory) name is CA followed by TRUE or FALSE. If CA is TRUE then an optional pathlen name followed by an non-negative value can be included. Also equivalent to the object ID (OID) value of 2.5.29.19. + + + + + The Name_Constraints field captures a name space within which all subject names in subsequent certificates in a certification path MUST be located. Also equivalent to the object ID (OID) value of 2.5.29.30. + + + + + The Policy_Constraints field captures any constraints on path validation for certificates issued to CAs. Also equivalent to the object ID (OID) value of 2.5.29.36. + + + + + The Key_Usage element field captures a multi-valued extension consisting of a list of names of the permitted key usages. Also equivalent to the object ID (OID) value of 2.5.29.15. + + + + + The Extended_Key_Usage field captures a list of usages indicating purposes for which the certificate public key can be used for. Also equivalent to the object ID (OID) value of 2.5.29.37. + + + + + The Subject_Key_Identifier field captures the identifier that provides a means of identifying certificates that contain a particular public key. Also equivalent to the object ID (OID) value of 2.5.29.14. + + + + + The Authority_Key_Identifier field captures the identifier that provides a means of identifying the public key corresponding to the private key used to sign a certificate. Also equivalent to the object ID (OID) value of 2.5.29.35. + + + + + The Subject_Alternative_Name field captures the additional identities to be bound to the subject of the certificate. Also equivalent to the object ID (OID) value of 2.5.29.17. + + + + + The Issuer_Alternative_Name field captures the additional identities to be bound to the issuer of the certificate. Also equivalent to the object ID (OID) value of 2.5.29.18. + + + + + The Subject_Directory_Attributes field captures the identification attributes (e.g., nationality) of the subject. Also equivalent to the object ID (OID) value of 2.5.29.9. + + + + + The CRL_Distribution_Points field captures how CRL information is obtained. Also equivalent to the object ID (OID) value of 2.5.29.31. + + + + + The Inhibit_Any_Policy field the number of additional certificates that may appear in the path before anyPolicy is no longer permitted. Also equivalent to the object ID (OID) value of 2.5.29.54. + + + + + The Private_Key_Usage_Period field captures the validity period for the private key, if it is different from the validity period of the certificate. Also equivalent to the object ID (OID) value of 2.5.29.16. + + + + + The Certificate_Policies field captures a sequence of one or more policy information terms, each of which consists of an object identifier (OID) and optional qualifiers. Also equivalent to the object ID (OID) value of 2.5.29.32. + + + + + The Policy_Mappings field captures one or more pairs of OIDs; each pair includes an issuerDomainPolicy and a subjectDomainPolicy. The pairing indicates whether the issuing CA considers its issuerDomainPolicy equivalent to the subject CA's subjectDomainPolicy. Also equivalent to the object ID (OID) value of 2.5.29.33. + + + + + + + The NonStandardX509ExtensionsType captures some non-standard or deprecated X509 extensions that may be useful. Based on the OpenSSL "Deprecated Extensions" documentation: https://www.openssl.org/docs/apps/x509v3_config.html#Deprecated_Extensions. Also based on the Alvestrand certificateExtension reference: http://www.alvestrand.no/objectid/2.5.29.html + + + + + The Netscape_Comment field captures a comment which may be displayed when the certificate is viewed in some browsers. + + + + + The Netscape_Certificate_Type field captures a list of flags which indicate the purposes for which a certificate could be used. + + + + + The Old_Authority_Key_Identifier captures the old version of the authority key identifier, equivalent to the object ID (OID) value of 2.5.29.1. + + + + + The Old_Primary_Key_Attributes field captures the old version of the primary key attributes, equivalent to the object ID (OID) value of 2.5.29.2. + + + + + diff --git a/stix_validator/schema/data_marking.xsd b/stix_validator/schema/data_marking.xsd new file mode 100755 index 0000000..be63323 --- /dev/null +++ b/stix_validator/schema/data_marking.xsd @@ -0,0 +1,92 @@ + + + + This schema was originally developed by The MITRE Corporation. The Data Marking XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + Data Marking + 1.0 + 04/08/2013 9:00:00 AM + Data_Marking - Schematic implementation for an independent, flexible, structured data marking expression. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the Data Marking Schema, this license header must be included. + + + + + + MarkingType specifies a structure for marking information to be applied to portions of XML content. + + + + + This field contains specification of marking information to be applied to portions of XML content. + + + + + + + + The MarkingStructureType contains the marking information to be applied to a portion of XML content. + + This type is defined as abstract and is intended to be extended to enable the expression of any structured or unstructured data marking mechanism. STIX provides two options: Simple, and TLP.Additionally, those who wish to use another format may do so by defining a new extension to this type. The information for the STIX-provided extensions is: + + 1. Simple: The Simple marking structures allows for the specification of unstructured statements through the use of a string field. The type is named SimpleMarkingStructureType and is in the http://data-marking.mitre.org/extensions/MarkingStructure#Simple-1 namespace. The extension is defined in the file extensions/marking/simple_marking.xsd or at the URL http://stix.mitre.org/XMLSchema/extensions/marking/simple_marking/1.0/simple_marking.xsd. + + 2. TLP: The TLP marking structure allows for the expression of Traffic Light Protocol statements through the use of a simple enumeration. The type is named TLPMarkingStructureType and is in the http://data-marking.mitre.org/extensions/MarkingStructure#TLP-1 namespace. The extension is defined in the file extensions/marking/tlp.xsd or at the URL http://stix.mitre.org/XMLSchema/extensions/marking/tlp/1.0/tlp.xsd. + + + + + This field specifies the name of the marking model to be applied within this Marking_Structure. + + + + + This field contains a reference to an authoritative source on the marking model to be applied within this Marking_Structure. + + + + + + + + + This field utilizes XPath 1.0 to specify the structures for which the Marking is to be applied. + + The XPath expression is NOT recursive and the marking structure does NOT apply to child nodes of the selected node. Instead, the expression must explicitly select all nodes that the marking is to be applied to including elements, attributes, and text nodes. + + The context root of the XPath statement is this Controlled_Structure element. Any namespace prefix declarations that are available to this Controlled_Structure element are available to the XPath. + + Note that all Controlled_Structure elements have a scope within the document for which their XPath is valid to reference. + Usages of MarkingType may specify a "marking scope". The marking scope is always recursive and specifies the set of nodes that may be selected by the XPath expression (and therefore that may have the markings applied to them). If no marking scope is specified in the schema documentation or specification where the MarkingType is used, it should be assumed that the document itself and all nodes are within scope. + + + + + + This field contains the marking information to be applied to the portions of XML content specified in the ControlledStructure field. This field is defined as MarkingStructureType which is an abstract type the enables the flexibility to utilize any variety of marking structures. + + + + + The Information_Source field details the source of this entry. + + + + + + Specifies a unique ID for this Marking. + + + + + Specifies a reference to the ID of a Marking defined elsewhere. + + + + + Specifies the relevant Data_Marking schema version for this content. + + + + diff --git a/stix_validator/schema/exploit_target.xsd b/stix_validator/schema/exploit_target.xsd new file mode 100755 index 0000000..8c6403f --- /dev/null +++ b/stix_validator/schema/exploit_target.xsd @@ -0,0 +1,223 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Exploit Target + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) - ExploitTarget - Schematic implementation for the ExploitTarget construct within the STIX structured cyber threat expression language architecture + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + The ExploitTarget field characterizes potential targets for exploitation. In other words characteristics about targeted victims that may make them vulnerable to attack. + + + + + + + + + The Title field provides a simple title for this ExploitTarget. + + + + + The Vulnerability field identifies and characterizes a Vulnerability as a potential ExploitTarget. + + + + + The Weakness field identifies and characterizes a Weakness as a potential ExploitTarget. + + + + + The Configuration field identifies and characterizes a Configuration as a potential ExploitTarget. + + + + + The Potential_COAs field specifies potential Courses of Action for this ExploitTarget. + + + + + The Information_Source field details the source of this entry. + + + + + The Handling field specifies the appropriate data handling markings for the elements of this Exploit Target. The valid marking scope is the nearest ExploitTargetBaseType ancestor of this Handling element and all its descendants. + + + + + + Specifies the relevant STIX-ExploitTarget schema version for this content. + + + + + + + + + An enumeration of all versions of the Exploit Target type valid in the current release of STIX. + + + + + + + + + Characterizes an individual vulnerability. + + In addition to capturing basic information and references to vulnerability registries, this type is intended to be extended to enable the structured description of a vulnerability by using the XML Schema extension feature. The STIX default extension uses the Common Vulnerability Reporting Format (CVRF) schema to do so. The extension that defines this is captured in the CVRF1.1InstanceType in the http://stix.mitre.org/extensions/Vulnerability#CVRF1.1-1 namespace. This type is defined in the extensions/vulnerability/cvrf_1.1.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/vulnerability/cvrf_1.1/1.0/cvrf_1.1.xsd. + + + + + + The Description element is optional and enables a generalized description of this Vulnerability. + + + + + The CVE_ID field is optional and specifies a CVE identifier for a particular vulnerability. + + + + + + + + + + The OSVDB_ID field is optional and specifies an OSVDB identifier for a particular vulnerability. + + + + + The CVSS_Score field captures the full CVSS v2.0 base, temporal, and environmental vectors in their string format. + + + + + + + + + + + The Potential_COA field specifies a potential Course of Action for this ExploitTarget. + + + + + + + + + + + The Description element is optional and enables a generalized description of this Configuration. + + + + + The CCE_ID field is optional and specifies a CCE identifier for a particular configuration item. + + + + + + + + + + + + + + The Description element is optional and enables a generalized description of this Weakness. + + + + + The CWE_ID element is optional and specifies a CWE identifier for a particular weakness. + + + + + + + + + + + + + + Captures the overall CVSS 2.0 score. Note that this is not the same as the unadjusted CVSS Base Score, which should be captured in the Base_Score field. + + + + + Captures the unadjusted CVSS 2.0 Base score. + + + + + Captures the CVSS 2.0 Base Vector per the compressed string format. + + + + + Captures the unadjusted CVSS 2.0 Temporal score. + + + + + Captures the CVSS 2.0 Temporal Vector per the compressed string format. + + + + + Captures the unadjusted CVSS 2.0 Environmental score. + + + + + Captures the CVSS 2.0 Environmental Vector in the compressed string format. + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/stix_validator/schema/extensions/address/ciq_address_3.0.xsd b/stix_validator/schema/extensions/address/ciq_address_3.0.xsd new file mode 100755 index 0000000..eda7fc1 --- /dev/null +++ b/stix_validator/schema/extensions/address/ciq_address_3.0.xsd @@ -0,0 +1,27 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Extension - CIQ Address 3.0 Instance + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) Extension - CIQ Address 3.0 Instance - Schematic implementation for the using version 3.0 of CIQ to describe an Address within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + The CIQAddress3.0InstanceType provides an extension to the AddressAbstractType which imports and leverages version 3.0 of the OASIS CIQ-PIL schema for structured characterization of Addresses. + + + + + + + + + + diff --git a/stix_validator/schema/extensions/address/readme.txt b/stix_validator/schema/extensions/address/readme.txt new file mode 100755 index 0000000..a941d36 --- /dev/null +++ b/stix_validator/schema/extensions/address/readme.txt @@ -0,0 +1 @@ +The default type for representing addresses is CIQAddress3.0InstanceType in ciq_address_3.0.xsd. \ No newline at end of file diff --git a/stix_validator/schema/extensions/attack_pattern/capec_2.5.xsd b/stix_validator/schema/extensions/attack_pattern/capec_2.5.xsd new file mode 100755 index 0000000..32fac89 --- /dev/null +++ b/stix_validator/schema/extensions/attack_pattern/capec_2.5.xsd @@ -0,0 +1,31 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Extension - CAPEC 2.5 Attack Pattern Instance + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) Extension - CAPEC Attack Pattern Instance - Schematic implementation for the using CAPEC 2.5 to describe an Attack Pattern within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + The CAPECInstanceType provides an extension to the APStructureAbstractType which imports and leverages the CAPEC schema for structured characterization of Attack Patterns. + + + + + + + The CAPEC field contains the structured specification of an Attack Pattern utilizing the CAPEC schema. + + + + + + + diff --git a/stix_validator/schema/extensions/identity/ciq_identity_3.0.xsd b/stix_validator/schema/extensions/identity/ciq_identity_3.0.xsd new file mode 100755 index 0000000..631dc97 --- /dev/null +++ b/stix_validator/schema/extensions/identity/ciq_identity_3.0.xsd @@ -0,0 +1,108 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Extension - CIQ Identity 3.0 Instance + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) Extension - CIQ Identity 3.0 Instance - Schematic implementation for the using version 3.0 of CIQ to describe an Identity within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + The CIQIdentity3.0InstanceType provides an extension to the IdentityStructureAbstractType which imports and leverages version 3.0 of the OASIS CIQ-PIL schema for structured characterization of Identities. + + + + + + + The Specification field contains the structured characterization of an Identity utilizing the CIQ-PIL schema. + + + + + The Role field specifies a relevant role played by this entity. + + + + + + + + + The STIXCIQIdentityType provides a restriction and minor extension of the imported OASIS CIQ-PIL PartyType for use in characterizing STIX Identities. + + + + + + + + + + A container to define the accounts details of the party such as utility account, financil accounts + + + + + + A container for identification document and cards of the party that are unique to the party. e.g. license, identification card, credit card, etc + + + + + + + + A container for memberships of party with other organisations (e.g. industry groups) or social networks (clubs, association, etc) + + + + + Relationships with other parties (persons or organisations, and the nature of relationship). Examples: - For person: Contacts, blood relatives, friends, referees, customers, etc - for Organisation: Subsidiary, Parent company, Branches, Divisions, Partners, etc + + + + + Container for income / revenue information of the party (salary/organisation revenue) + + + + + + + Container for other organisation specific details that are not covered in this schema that are common to a party + + + + + Container for other person specific details that are not covered in this schema elements that are common to a party + + + + + + + + + + + + + + + + + + Type of Party. e.g. Person or an organisation. An organisation could be university, college, club, association, company, etc + + + + + + diff --git a/stix_validator/schema/extensions/identity/readme.txt b/stix_validator/schema/extensions/identity/readme.txt new file mode 100755 index 0000000..2540f3b --- /dev/null +++ b/stix_validator/schema/extensions/identity/readme.txt @@ -0,0 +1 @@ +The default type for representing identities is CIQIdentity3.0InstanceType in ciq_identity_3.0.xsd. \ No newline at end of file diff --git a/stix_validator/schema/extensions/malware/maec_4.0.xsd b/stix_validator/schema/extensions/malware/maec_4.0.xsd new file mode 100755 index 0000000..9bb2f50 --- /dev/null +++ b/stix_validator/schema/extensions/malware/maec_4.0.xsd @@ -0,0 +1,32 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + NOTICE: This schema is not currently live. Once MAEC 4.0 is released, the URLs referenced below will resolve and the schema will be usable. Please refer to the MAEC website and mailing lists for more information on when it will be released. + + STIX Extension - MAEC Malware Instance + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) Extension - MAEC 4.0 Malware Instance - Schematic implementation for the using MAEC 4.0 to describe Malware within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + The MAEC4.0InstanceType provides an extension to MalwareInstanceType which imports and leverages the MAEC 4.0 schema for structured characterization of Malware. + + + + + + + The MAEC field contains the structured characterization of instances of Malware utilizing the MAEC Package schema. + + + + + + + diff --git a/stix_validator/schema/extensions/malware/readme.txt b/stix_validator/schema/extensions/malware/readme.txt new file mode 100755 index 0000000..f3418f9 --- /dev/null +++ b/stix_validator/schema/extensions/malware/readme.txt @@ -0,0 +1,3 @@ +The default type for representing identities is the MAEC4.0InstanceType defined in maec_4.0.xsd. + +Please note that this extension is targeted against MAEC 4.0. At the time of the STIX 1.0 release MAEC 4.0 has not been released and the extension will not validate. Once MAEC 4.0 is released the STIX team will notify the community and the extension will start to work. \ No newline at end of file diff --git a/stix_validator/schema/extensions/marking/simple_marking.xsd b/stix_validator/schema/extensions/marking/simple_marking.xsd new file mode 100755 index 0000000..ad70918 --- /dev/null +++ b/stix_validator/schema/extensions/marking/simple_marking.xsd @@ -0,0 +1,30 @@ + + + + This schema was originally developed by The MITRE Corporation. The Data Marking Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + Data Marking Extension - Simple Marking Instance + 1.0 + 04/08/2013 9:00:00 AM + Data Marking Extension - Simple Marking Instance - Schematic implementation for attaching a simple statement to an idendified XML structure. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + The SimpleMarkingStructureType is a basic implementation of the data marking schema that allows for a string statement to be associated with the data being marked. One example might be the application of a copyright statement to some data set. + + + + + + + The statement to apply to the structure for which the Marking is to be applied. + + + + + + + diff --git a/stix_validator/schema/extensions/marking/tlp.xsd b/stix_validator/schema/extensions/marking/tlp.xsd new file mode 100755 index 0000000..2bf027f --- /dev/null +++ b/stix_validator/schema/extensions/marking/tlp.xsd @@ -0,0 +1,39 @@ + + + + This schema was originally developed by The MITRE Corporation. The Data Marking Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + Data Marking Extension - TLP + 1.0 + 04/08/2013 9:00:00 AM + Data Marking Extension - TLP Marking Instance - Schematic implementation for attaching a Traffic Light Protocol (TLP)designation to an idendified XML structure. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + The TLPMarkingStructureType is an implementation of the data marking schema that allows for a TLP Designation to be attached to an identified XML structure. Information about TLP is available here: http://www.us-cert.gov/tlp. + + + + + + The TLP color designation of the marked structure. + + + + + + + + The TLP color designation of the marked structure. + + + + + + + + + diff --git a/stix_validator/schema/extensions/structured_coa/generic.xsd b/stix_validator/schema/extensions/structured_coa/generic.xsd new file mode 100755 index 0000000..0bcfda3 --- /dev/null +++ b/stix_validator/schema/extensions/structured_coa/generic.xsd @@ -0,0 +1,46 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Extension - Structured Course of Action Instance + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) Extension - Generic Structured Course of Action Instance - Schematic implementation for the using a generic Structured Course of Action within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + The GenericStructuredCOAType specifies an instantial extension from the abstract StructuredCOAType intended to support the generic inclusion of any COA content. + + + + + + + A structured Description of this Generic Structured COA. + + + + + Specifies the type of Generic Structured COA. + + + + + The Specification field encapsulates any test mechnism specification in its native format within a string field. The specification should be within a CDATA construct within the string field. + + + + + + Specifies a reference URL for the location of the Generic Structured COA. + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/extensions/test_mechanism/generic.xsd b/stix_validator/schema/extensions/test_mechanism/generic.xsd new file mode 100755 index 0000000..568d9f4 --- /dev/null +++ b/stix_validator/schema/extensions/test_mechanism/generic.xsd @@ -0,0 +1,46 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Extension - Generic Test Mechanism Instance + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) Extension - Generic Test Mechanism Instance - Schematic implementation for the using a generic Test Machanism within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + The GenericTestMechanismType specifies an instantial extension from the abstract TestMechanismType intended to support the generic inclusion of any test mechanism content. + + + + + + + A structured Description of this Generic Test Mechanism. + + + + + Specifies the type of Generic Test Mechanism. + + + + + The Specification field encapsulates any test mechnism specification in its native format within a string field. The specification should be within a CDATA construct within the string field. + + + + + + Specifies a reference URL for the location of the Generic Test Mechanism. + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/extensions/test_mechanism/open_ioc_2010.xsd b/stix_validator/schema/extensions/test_mechanism/open_ioc_2010.xsd new file mode 100755 index 0000000..a53f0cb --- /dev/null +++ b/stix_validator/schema/extensions/test_mechanism/open_ioc_2010.xsd @@ -0,0 +1,32 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Extension - Open IOC Test Mechanism Instance + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) Extension - Open IOC Test Mechanism Instance - Schematic implementation for the using the 2010 version of Open IOC to describe a Test Machanism within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + + The OpenIOC2010TestMechanismType provides an extension to the TestMechanismType which imports and leverages the 2010 Open IOC schema in order to include OpenIOC elements as the test mechanism. + + + + + + + The ioc field contains the structured specification of the OpenIOC test mechanism. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/extensions/test_mechanism/oval_5.10.xsd b/stix_validator/schema/extensions/test_mechanism/oval_5.10.xsd new file mode 100755 index 0000000..4a29e33 --- /dev/null +++ b/stix_validator/schema/extensions/test_mechanism/oval_5.10.xsd @@ -0,0 +1,37 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Extension - OVAL Test Mechanism Instance + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) Extension - OVAL Test Mechanism Instance - Schematic implementation for the using OVAL to describe a Test Machanism within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + + The OVALTestMechanismType provides an extension to the TestMechanismType which imports and leverages the OVAL schema in order to include OVAL Definitions as the test mechanism. + + + + + + + The oval_definitions field contains the structured specification of the OVAL test mechanism. When including OVAL Definition documents it is expected that at least one valid OVAL Definition Definition is included. + + + + + The oval_variables field contains a valid OVAL Variables document and should only be used to supply external variable values needed by this OVAL Test Mechanism's OVAL Definitions. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/extensions/test_mechanism/snort.xsd b/stix_validator/schema/extensions/test_mechanism/snort.xsd new file mode 100755 index 0000000..8039763 --- /dev/null +++ b/stix_validator/schema/extensions/test_mechanism/snort.xsd @@ -0,0 +1,36 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Extension - Snort Test Mechanism Instance + 1.0 + 03/21/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) Extension - Snort Test Mechanism Instance - Schematic implementation for the using a Snort rule as a Test Machanism within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + The SnortTestMechanismType specifies an instantial extension from the abstract TestMechanismType intended to support the inclusion of a Snort rule as a test mechanism content. + + + + + + + The Version of Snort that the rule was written against. + + + + + The Rule field encapsulates a Snort rule in its native format within a String field. The specification should be within a CDATA construct within the String field. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/extensions/test_mechanism/yara.xsd b/stix_validator/schema/extensions/test_mechanism/yara.xsd new file mode 100755 index 0000000..223ee89 --- /dev/null +++ b/stix_validator/schema/extensions/test_mechanism/yara.xsd @@ -0,0 +1,36 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Extension - YARA Test Mechanism Instance + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) Extension - YARA Test Mechanism Instance - Schematic implementation for the using a YARA rule as a Test Machanism within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + The YaraTestMechanismType specifies an instantial extension from the abstract TestMechanismType intended to support the inclusion of a YARA rule as a test mechanism content. + + + + + + + The Version of YARA that the rule was written against. + + + + + The Rule field encapsulates a YARA rule in its native format within a String field. The specification should be within a CDATA construct within the String field. + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/extensions/vulnerability/cvrf_1.1.xsd b/stix_validator/schema/extensions/vulnerability/cvrf_1.1.xsd new file mode 100755 index 0000000..f9f6d89 --- /dev/null +++ b/stix_validator/schema/extensions/vulnerability/cvrf_1.1.xsd @@ -0,0 +1,33 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Extension - CVRF 1.1 Vulnerability Instance + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) Extension - CVRF 1.1 Vulnerability Instance - Schematic implementation for the using version 1.1 of CVRF to describe an Vulneability within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + + The CVRF1.1InstanceType provides an extension to the VulnerabilityType which imports and leverages the CVRF schema for structured characterization of Vulnerabilities. This could include characterization of 0-days or other vulnerabilities that do not have a CVE or OSVDB ID. + + + + + + + + The CVRF field contains the structured characterization of Vulnerabilities utilizing the CVRF schema. + + + + + + + diff --git a/stix_validator/schema/extensions/vulnerability/readme.txt b/stix_validator/schema/extensions/vulnerability/readme.txt new file mode 100755 index 0000000..29e7132 --- /dev/null +++ b/stix_validator/schema/extensions/vulnerability/readme.txt @@ -0,0 +1 @@ +The default type for representing vulnerabilities in STIX is CVRF1.1InstanceType in cvrf1.1.xsd \ No newline at end of file diff --git a/stix_validator/schema/external/capec_2.5/ap_schema_v2.5.xsd b/stix_validator/schema/external/capec_2.5/ap_schema_v2.5.xsd new file mode 100755 index 0000000..fb0c284 --- /dev/null +++ b/stix_validator/schema/external/capec_2.5/ap_schema_v2.5.xsd @@ -0,0 +1,2671 @@ + + + + + + This is the enumerated catalog of common attack patterns. + + + + + + + + + + + + + + + + A category is a collection of attack patterns sharing a common attribute. The shared attribute may any number of things. + + + + + + + + + + + + + + + + + + The Compound_Element structure represents a meaningful aggregation of several attack patterns. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Each View element represents a perspective with which one might look at the attack patterns in CAPEC. + + + + + The View_Attributes structure is a collection of common elements which might be shared by all Views. + + + + + The ID attribute provides a unique identifier for the entry. It will be static for the lifetime of the entry. In the event that this entry becomes deprecated, the ID will not be reused and a pointer will be left in this entry to the replacement. This is required for all Views. + + + + + The Name is a descriptive attribute used to give the reader an idea of what perspective this view represents. All words in the name should be capitalized except for articles and prepositions unless they begin or end the name. Subsequent words in a hyphenated chain are also not capitalized. This is required for all Views. + + + + + The Status attribute defines the status level for this view. + + + + + + + + + + + This field provides a description of this Category. Its primary subelement is Description_Summary which is intended to serve as a minimalistic description which provides the information necessary to understand the primary focus of this entry. Additionally, it has the subelement Extended_Description which is optional and is used to provide further information pertaining to this attack pattern. + + + + + + This description should be short and should limit itself to describing the key points that define this entry. Further explanation can be included in the extended description element. This is required for all entries. + + + + + This element provides a place for details important to the description of this entry to be included that are not necessary to convey the fundamental concept behind the entry. This is not required for all entries and should only be included where appropriate. + + + + + + + + Which specific weaknesses does this attack target and leverage? Specific weaknesses (underlying issues that may cause vulnerabilities) reference the industry-standard Common Weakness Enumeration (CWE). This list should include not only those weaknesses that are directly targeted by the attack but also those whose presence can directly increase the likelihood of the attack succeeding or the impact if it does succeed. + + + + + + This field describes an individual related weakness. + + + + + + The CWE_ID is a field that exists for all weaknesses enumerated in the Common Weakness Enumeration (CWE). It is a unique value that allows each weakness to be unambiguously identified. The CWE_ID field for the attack pattern contains the value of the CWE_ID for the specific related weakness. + + + + + This field describes the nature of the relationship between this weakness and the attack pattern. Weaknesses that are specifically targeted by the attack are of type "Targeted". Weaknesses which are not specifically targeted but whose presence may increase the likelihood of the attack succeeding or the impact of the attack if it does succeed are of type "Secondary". + + + + + + + + + + + + + + + + + This field describes the conditions that must exist or the functionality and characteristics that the target software must have or behavior it must exhibit for an attack of this type to succeed. + + + + + + This field describes an individual attack prerequisite. + + + + + + + + This field describes the mechanism of attack used by this pattern. This field can help define the applicable attack surface required for this attack. + + + + + + This field describes the mechanism of attack used by this pattern. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined vectors which is currently incomplete and will grow as new relevant vectors are identified. This field can help define the applicable attack surface required for this attack. + + + + + + + + + + + + + + + + + + + + + + This field describes the level of skills or specific knowledge required by an attacker to execute this type of attack. + + + + + + This field describes the level of skill or specific knowledge required by an attacker to execute this type of attack. + + + + + + This should be communicated on a rough scale (Low, Medium, High). +For example: +• Low - Basic computer familiarity +• Low - Basic SQL knowledge +• Medium - Moderate scripting and shell experience and ability to disassemble and decompile +• High - Expert knowledge of LINUX kernel +• High - Detailed knowledge of target software development practices and business context (former employee) +• Etc. + + + + + + + + + + + + + This field provides contextual detail for the skill or knowledge level. + + + + + + + + + + + This field describes the resources (CPU cycles, IP addresses, tools, etc.) required by an attacker to effectively execute this type of attack. + + + + + What is the attacker trying to achieve by using this attack? This is not the end business/mission goal of the attack within the target context but rather the specific technical result desired that could be leveraged to achieve the end business/mission objective. This information is useful for aligning attack patterns to threat models and for determining which attack patterns are relevant for a given context. + + + + + + What is the attacker trying to achieve by using this attack? This is not the end business/mission goal of the attack within the target context but rather the specific technical result desired that could be leveraged to achieve the end business/mission objective. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined motivations/consequences which is currently incomplete and will grow as new relevant possibilities are identified. This information is useful for aligning attack patterns to threat models and for determining which attack patterns are relevant for a given context. + + + + + + + + The Relationships structure contains one or more Relationship elements, each of which identifies an association between this structure, whether it is an Attack Pattern, Category, or Compound_Element and another structure. + + + + + + This structure houses one or more Relationship_Note elements, which each contain details regarding the relationships between CAPEC entries. + + + + + This element contains one or more Maintenance_Note elements which each contain significant maintenance tasks within this entry that still need to be addressed, such as clarifying the concepts involved or improving relationships. It should be filled out in any entry that is still undergoing significant review by the +CAPEC team. + + + + + This structure contains one or more Background_Detail elements, each of which holds information regarding the entry or any technologies that are related to it, where the background information is not related to the nature of the entry itself. It should be filled out where appropriate. + + + + + + This element contains background information regarding the entry or any technologies that are related to it, where the background information is not related to the nature of the category itself. It should be filled out where appropriate. + + + + + + + + + This element contains one or more Note elements, each of which provide any additional notes or comments that cannot be captured using other elements. New elements might be defined in the future to contain this information. It should be filled out where needed. + + + + + This element contains one or more Alternate_Term elements, each of which contains other names used to describe this attack pattern. + + + + + This structure contains one or more Research gap elements, each of which identifies potential opportunities for the vulnerability research community to conduct further exploration of issues related to this attack pattern. It is intended to highlight parts of CAPEC that have not received sufficient attention from researchers. +This should be filled out where appropriate for attack patterns and categories. + + + + + The References element contains one or more Reference elements, each of which provide further reading and insight into this +attack pattern. + + + + + This element is used to keep track of the author of the attack pattern entry and anyone who has made modifications to the content. This provides a means of contacting the authors and modifiers for clarifying ambiguities, merging overlapping contributions, etc. This should be filled out for all entries. + + + + + + This attribute provides a unique identifier for the entry. It will be static for the lifetime of the entry. In the event that this entry becomes deprecated, the ID will not be reused and a pointer will be left in this entry to the replacement. This is required for all Categories. + + + + + The Name is a descriptive name used to give the reader an idea of what the commonality is amongst the children of this category. All + words in the name should be capitalized except for articles and prepositions unless they begin or end the name. Subsequent words in a hyphenated chain are also not capitalized. This is required for all Categories. + + + + + The Status attribute defines the status level for this category. + + + + + + + This element is an individual attack pattern. + + + + + + + + This field provides a description of this Structure, whether it is an Attack Pattern, Category or Compound Element. Its primary subelement is Description_Summary which is intended to serve as a minimalistic description which provides the information necessary to understand the primary focus of this entry. Additionally, it has the subelement Extended_Description which is optional and is used to provide further information pertaining to this attack pattern. + + + + + + This description should be short and should limit itself to describing the key points that define this entry. Further explanation can be included in the extended description element. This is required for all entries. + + + + + This element provides a place for details important to the description of this entry to be included that are not necessary to convey the fundamental concept behind the entry. This is not required for all entries and should only be included where appropriate. + + + + + + + + The Relationships structure contains one or more Relationship elements, each of which identifies an association between this structure, whether it is an Attack Pattern, Category, or Compound_Element and another structure. + + + + + + This structure houses one or more Relationship_Note elements, which each contain details regarding the relationships between CAPEC entries. + + + + + This element contains one or more Maintenance_Note elements which each contain significant maintenance tasks within this entry that still need to be addressed, such as clarifying the concepts involved or improving relationships. It should be filled out in any entry that is still undergoing significant review by the +CAPEC team. + + + + + This structure contains one or more Background_Detail elements, each of which holds information regarding the entry or any technologies that are related to it, where the background information is not related to the nature of the entry itself. It should be filled out where appropriate. + + + + + + This element contains background information regarding the entry or any technologies that are related to it, where the background information is not related to the nature of the attack pattern itself. It should be filled out where appropriate. + + + + + + + + + This element contains one or more Note elements, each of which provide any additional notes or comments that cannot be captured using other elements. New elements might be defined in the future to contain this information. It should be filled out where needed. + + + + + This element contains one or more Alternate_Term elements, each of which contains other names used to describe this attack pattern. + + + + + This structure contains one or more Research gap elements, each of which identifies potential opportunities for the vulnerability research community to conduct further exploration of issues related to this attack pattern. It is intended to highlight parts of CAPEC that have not received sufficient attention from researchers. +This should be filled out where appropriate for attack patterns and categories. + + + + + The References element contains one or more Reference elements, each of which provide further reading and insight into this +attack pattern. + + + + + This element is used to keep track of the author of the attack pattern entry and anyone who has made modifications to the content. This provides a means of contacting the authors and modifiers for clarifying ambiguities, merging overlapping contributions, etc. This should be filled out for all entries. + + + + + + This attribute provides a unique identifier for the entry. It will be static for the lifetime of the entry. In the event that this entry becomes deprecated, the ID will not be reused and a pointer will be left in this entry to the replacement. This is required for all Compound_Elements. + + + + + The Name is a descriptive name used to give the reader an idea of the meaning behind the compound attack pattern structure. All words in the name should be capitalized except for articles and prepositions unless they begin or end the name. Subsequent words in a hyphenated chain are also not capitalized. This is required for all Compound_Elements. + + + + + The Abstraction defines the abstraction level for this attack pattern. The abstraction levels for Compound_Elements and Attack Patterns are the same. For example, if the Compound_Element is a chain, and all elements of the chain are Meta level, then the Compound_Element Abstraction attribute is Meta. This is required for all Compound_Elements. + + + + + + + + + + + + + + + + + + + + + The Structure attribute defines the structural nature of this compound element - that is, composed of other attack patterns concurrently, as in a composite, or consecutively, as in a chain. + + + + + + + + + + + The Status attribute defines the status level for this compound element. + + + + + + + + Description and globally unique ID for a kind of environment or + context that is required. Used in Attack Steps, Indicators of Susceptibility, + and Security Controls, etc. + + + + + + + + + + + + + + + + + Segment the attack steps into the various phases of attack. One of three phases "Explore," "Experiment," or "Exploit." Each phase should appear at most once, and attack steps should be grouped by what kind of activities the attacker is carrying out. The exploration and experimentation phases may or may not occur during a particular attack, because the attacker may already know exactly how to exploit a system. + + + + + One of three phases "Explore," "Experiment," or +"Exploit." Each phase should appear at most once, and attack steps should be grouped by what kind of activities the attacker is carrying out. + + + + + + + Brief description of an individual action step + in carrying out the attack + + + + + + + + + + + + + + + + + + + + + + + + "Explore," "Experiment," or "Exploit." + + + + + + + + + + + + + + + + + + + + + + + A particular technique that may accomplish this attack step. + + + + + + This field contains a brief description of the attack step technique. + + + + + + + + + + + + + + References the defined environments where this attack step technique is applicable. + + + + + + + + + The View_Attributes structure is a collection of common elements which might be shared by all Views. + + + + + The View_Structure element describes how this view is being constructed. Valid values are: Implicit Slice = a slice based on a filter criteria; Explicit Slice = a slice based on arbitrary membership, as defined by specific relationships between entries; Graph = a bounded graphical slice based on ChildOf relationships. + + + + + + + + + + + + The View_Objective element describes the perspective from which this View is constructed. + + + + + The View_Audience element provides a reference to the targeted audiences or groups for this view. + + + + + + The Audience element provides a reference to the +target audience or group for this view. + + + + + + The Stakeholder element specifies what types of members of the CAPEC community might be +interested in this view. + + + + + + + + + + + + + + + + + + + + + + The Stakeholder_Description el provides some text describing what properties of this View this particular Stakeholder might find +useful. + + + + + + + + + + + The Relationships structure contains one or more Relationship elements, each of which identifies an association between this structure, whether it is a Attack Pattern, Category, or Compound_Element and another structure. + + + + + This structure houses one or more Relationship_Note elements, which each contain details regarding the relationships between CAPEC entries. + + + + + + This element contains one or more Maintenance_Note elements which each contain significant maintenance tasks within this entry that still need to be addressed, such as clarifying the concepts involved or improving relationships. It should be filled out in any entry that is still undergoing significant review by the CAPEC team. + + + + + This element contains one or more Note elements, each of which provide any additional notes or comments that cannot be captured using other elements. New elements might be defined in the future to contain this information. It should be filled out where needed. + + + + + This element contains one or more Alternate_Term elements, each of which contains other names used to describe this attack pattern. + + + + + This structure contains one or more Research gap elements, each of which identifies potential opportunities for the vulnerability research community to conduct further exploration of issues related to this attack pattern. It is intended to highlight parts of CAPEC that have not received sufficient attention from researchers. This should be filled out where appropriate for attack patterns and categories. + + + + + The References element contains one or more Reference elements, each of which provide further reading and insight into this view. This should be filled out when the view is based on sources or projects that are external to the CAPEC project. + + + + + The View_Filter element holds an XSL query for identifying which elements are members of an implicit slice. This should only be present for implicit slices. + + + + + This element is used to keep track of the author of the attack pattern entry and anyone who has made modifications to the content. This provides a means of +contacting the authors and modifiers for clarifying ambiguities, merging overlapping contributions, etc. This should be filled out for all entries. + + + + + + + The Relationships structure contains one or more Relationship elements, each of which identifies an association between this structure, whether it is a Attack Pattern, Category, or Compound_Element and another structure. + + + + + + Each Relationship identifies an association between this structure, whether it is an Attack Pattern, Category, or Compound_Element and another structure. The relationship also identifies the views under which the relationship is applicable. + + + + + + + + + + This element contains a list of the individual Views to which this relationship pertains. + + + + + + Specifies the unique ID of the individual view element to which this relationship pertains. This ID must correspond to a View. + + + + + + + The ordinal attribute is used +to determine if this relationship is the primary ChildOf relationship for this + entry for a given Relationship_View_ID element.. This attribute can only have the value "Primary" and should only be included for the primary parent/child relationship. + + + + + + + + + + + + + + + + + + This element contains a list of the individual Chains this relationship pertains to. + + + + + + This element specifies the unique ID of an individual chain element this relationship pertains to. + + + + + + + + The Relationship_Target_Form element defines the form of the target of this relationship, such as Category, Attack Pattern, View or Compound_Element. + + + + + + + + + + + + + The Relationship_Nature element defines the nature of the relationship between this element and the target element, such as ChildOf, HasMember or Requires to name a few. + + + + + + This Relationship_Nature denotes the + specified entry as a top level member of this View. This + value for Relationship_Nature can only be used in Views. The + complementary relationship is MemberOf. + + + + + This Relationship_Nature denotes membership of + this entry in the top level of the View specified in + Relationship_Target_ID. The complementary relationship is + HasMember. + + + + + This Relationship_Nature denotes a specified + entry as a parent of this entry. In general, this means + that the parent will be a higher level representation of + this entry from the perspective of the View provided in + Relationship_View_ID. The complementary relationship is + ParentOf. + + + + + This Relationship_Nature denotes a specified + entry as a child of this entry. In general, this means + that the child will be a lower level representation of this + entry from the perspective of the View provided in + Relationship_View_ID. The complementary relationship is + ChildOf. + + + + + This Relationship_Nature denotes a specified + entry as having some similarity with this entry which does + not fit any of the other Relationship_Nature values. In this + case, a Relationship_Note should also be provided explaining + the connection. The complementary relationship is itself + (PeerOf). + + + + + This Relationship_Nature denotes a + Compound_Element of Compound_Element_Structure="Composite". + All entries that a Composite Requires must exist + simultaneously in order for the Compound_Element to exist. + The complementary relationship is + RequiredBy. + + + + + This Relationship_Nature denotes an entry + that is required in order for the Compound_Element specified + in Relationship_Target_ID to exist. The complementary + relationship is Requires. + + + + + This Relationship_Nature denotes the starting + point in this chain as the entry specified by + Relationship_Target_ID. This Relationship_Nature can only be + used for Compound_Elements with + Compound_Element_Structure="Chain". For named chains, the + complementary relationship is + StartsChain. + + + + + This Relationship_Nature denotes this entry + as the starting point in the chain specified in + Relationship_Target_ID. For named chains, the complementary + relationship is StartsWith. + + + + + This Relationship_Nature denotes a chain where + this entry can precede the entry specified by + Relationship_Target_ID in a sequential fashion. It is + important to note that not all CanPrecede relationships are + captured in a Compound_Element chain, only the most common + for now. The complementary relationship is + CanFollow. + + + + + This Relationship_Nature denotes a chain where + this entry can follow the entry specified by + Relationship_Target_ID in a sequential fashion. It is + important to note that not all CanFollow relationships are + captured in a Compound_Element chain, only the most common + for now. The complementary relationship is + CanPrecede. + + + + + This Relationship_Nature denotes an entry + that, in the proper environment and context, can also be + perceived as the entry specified by Relationship_Target_ID. + This relationship is not necessarily reciprocal. + + + + + + + + + The Relationship_Target_ID specifies the unique ID of the +target element of the relationship. + + + + + + + + This structure houses one or more Relationship_Note elements, which each contain details regarding the relationships between CAPEC entries. + + + + + + + This element contains a note regarding the relationships between CAPEC entries. + + + + + + + + This element contains one or more Maintenance_Note elements which each contain significant maintenance tasks within this entry that still need to be addressed, such as clarifying the concepts involved or improving relationships. It should be filled out in any entry that is still undergoing significant review by the CAPEC team. + + + + + + This element describes a significant maintenance task + within this entry that still need to be addressed, such as clarifying the concepts involved or improving relationships. It should be filled out in any entry that is still undergoing significant review by the CAPEC team. + + + + + + + + This element contains one or more Note elements, each of which provide any additional notes or comments that cannot be captured using other elements. New elements might be defined in the future to contain this information. It should be filled out where needed. + + + + + + This element contains any additional notes or comments +that cannot be captured using other elements. New elements might be defined in the future to contain this information. It should be filled out where needed. + + + + + + + + This element contains one or more Alternate_Term elements, each of which contains other names used to describe this attack pattern. + + + + + + This element contains alternate terms by which this +attack pattern may be known and a description to explain the context in which the term may be relevant. This is not required for all entries and should only be included where appropriate. + + + + + + This element contains the actual term for the Alternate_Term element. Each term should follow the same conventions as the entry Name attribute. + + + + + This element provides context to each +Alternate_Term by which this attack pattern may be known. + + + + + + + + + + + This structure contains one or more Research gap elements, each of which identifies potential opportunities for the attack research community to conduct further exploration of issues related to this attack pattern. It is intended to highlight parts of CAPEC that have not received sufficient attention from researchers. This should be filled out where appropriate for attack patterns and categories. + + + + + + This element identifies potential opportunities for the +vulnerability research community to conduct further exploration of issues related to this attack pattern. It is intended to highlight parts of CAPEC that have not received sufficient attention from researchers. This should be filled out where appropriate for attack patterns and categories. + + + + + + + + This element is used to keep track of the author of the attack pattern entry and anyone who has made modifications to the content. This provides a means of contacting the authors and modifiers for clarifying ambiguities, merging overlapping contributions, etc. This should be filled out for all entries. + + + + + + This structure contains one or more Submission elements. + + + + + + This element houses the subelements which identify the submitter and the submitter's comments related to this entry. This element has a single attribute, Submission_Source, which provides a general idea of how the initial information for this entry was obtained, whether internal to the CAPEC team, external, donated, etc. + + + + + + This element should contain the name of the author for this entry. + + + + + This element should identify the author's organization. + + + + + This element should provide the date on which this content was authored in YYYY-MM-DD format. + + + + + This element provides the author with a place to store any comments regarding the content of this attack pattern entry, such as assumptions made, reasons for omitting elements, contact information, pending questions, etc. + + + + + + This attribute identifies how the initial information for this entry was obtained. + + + + + + + + + + + + + + + + + + This structure contains one or more Contribution elements. + + + + + + This element houses the subelements which identify the contributor and contributor's comments related to this entry. This element has a single attribute, Contribution_Mode, which indicates whether the contribution was part of feedback given to the CAPEC team or actual content that was donated. + + + + + + This element should contain the name of the author for this entry. + + + + + This element should identify the author's organization. + + + + + This element should provide the date on which this content was authored in YYYY-MM-DD format. + + + + + This element provides the author with a place to store any comments regarding the content of this attack patterns entry, such as assumptions made, reasons for omitting elements, contact information, pending questions, etc. + + + + + + This attribute indicates whether the contribution was part of feedback given to the CAPEC team or actual content that was donated. + + + + + + + + + + + + + + + + This structure contains one or more Modification elements. + + + + + + This element houses the subelements which identify the modifier and modifier's comments related to this entry. A new Modification element should exist for each modification of the entry content. This element has a single attribute, Modification_Source, which indicates whether this modification was made by a CAPEC team member or an external party. + + + + + + This element should contain the name of the person modifying this entry. + + + + + This element should contain the modifier's organization. + + + + + This element should contain the date of the modifications. + + + + + This element provides the modifier with a place to store any comments regarding the content of this attack pattern entry, such as assumptions made, reasons for omitting elements, contact information, pending questions, etc. + + + + + + This attribute identifies how significant the modification is to the attack pattern with regard to the meaning and interpretation of the pattern. If a modification has a value of Critical, then the meaning of the entry or how it might be interpreted has changed and requires attention from anyone previously dependent on the attack pattern. + + + + + + + + + + + This attribute indicates whether this modification was created by a CAPEC team member or provided by an + external party. + + + + + + + + + + + + + + + + This structure contains one or more Previous_Entry_Name elements, each of which describes a previous name that was used for this entry. This should be filled out whenever a substantive name change occurs. + + + + + + This element identifies a name that was previously used for this entry. + + + + + + + This lists the date on which this name was changed to something else. Typically, this date will be closely aligned with new releases of CAPEC. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Block is a Structured_Text element consisting of one of Text_Title, Text, Code_Example_Language, or Code followed by another Block element. Structured_Text elements help define whitespace and text segments. + + + + + + + + + + + Presentation Element: This element is used to definebold-faced title for a subsequent block of text. + + + + + Presentation Element: This element is used to define a paragraph of text. + + + + + Presentation Element: This element is used to identify the programming language being used in the following block of Code + + + + + Presentation Element: This element is used to define a line of code. + + + + + Presentation Element: This element is used to define a + comment in code. + + + + + Presentation Element: This element is used to define an + image. + + + + + + Presentation Element: This element is used to define an image. + + + + + + This element provides the location of the image file. + + + + + This element provides a title for the image. + + + + + + + + + + + + + + Block is a Structured_Text element consisting of one of Text_Title, + Text, Code_Example_Language, or Code followed by another Block element. + Structured_Text elements help define whitespace and text segments. + + + + + + + + Block is a Structured_Text element consisting of one of Text_Title,Text, Code_Example_Language, or Code followed by another Block element. Structured_Text elements help define whitespace and text segments. + + + + + + This attribute identifies the nature of the content containedwithin the Block. + + + + + + + + + + + + + + + + + The References_List_Type contains one or more Reference elements, each + of which provide further reading and insight into the item. This should be filled + out as appropriate. + + + + + Each Reference subelement should provide a single source from which more information and deeper insight can be obtained, such as a research paper or an excerpt from a publication. Multiple Reference subelements can exist. The sole attribute of this element is the id. The id is optional and translates to a preceding footnote below the context notes if the author of the entry wants to cite a reference. Not all subelements need to be completed, since some are designed for web references and others are designed for book references. The fields Reference_Author and Reference_Title should be filled out for all references if possible. Reference_Section and Reference_Date can be included for either book references or online references. Reference_Edition, Reference_Publication, Reference_Publisher, and Reference_PubDate are intended for book references, + however they can be included where appropriate for other types of references. Reference_Link is intended for web references, however it can be included for book references as well if applicable. + + + + + + + + + + This element identifies an individual author of the material being referenced. It is not required, but may be repeated sequentially in order to identify multiple authors for a single piece of material. + + + + + This element identifies the title of the material beingreferenced. It is not required if the material does not have a title. + + + + + This element is intended to provide a means of identifying the exact location of the material inside of the publication source, such as the relevant pages of a research paper, the appropriate chapters from a book, etc. This is useful for both book references and internet references. + + + + + This element identifies the edition of the material being + referenced in the event that multiple editions of the material exist. This will usually only be useful for book references. + + + + + This element identifies the publication source of the reference material, if one exists. + + + + + This element identifies the publisher of the reference material, if one exists. + + + + + This element identifies the date when the reference was included in the entry. This provides the reader with a time line for when the material in the reference, usually the link, was valid. The date should be of the format YYYY-MM-DD. + + + + + This field describes the date when the reference was published YYYY. + + + + + This element should hold the URL for the material being referenced, if one exists. This should always be used for web references, and may optionally be used for book and other publication references. + + + + + + The id attribute is optional and is used as a mechanism forciting text in the entry. If an id is provided, it is placed between brackets and precedes this reference and the matching id should be used inside of the text for the attack pattern itself where this reference is applicable. All reference ids assigned within an entry must be unique. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + This field contains a short descriptive title for the attack step. It should be kept as short as possible but also clearly convey the nature of the attack step being described. + + + + + This field contains a brief description of the attack step. + + + + + + + + This field captures various techniques that the attacker can use to achieve the attack step's goal. For example, an attacker may use tools such as WebScarab and Tamper Data in the experimentation phase of a SQL Injection attack pattern. The techniques include references to environments, because not all techniques work in all environments + + + + + + + + + + + These are indicators that the application may or may not be susceptible to the given attack step (not necessarily the pattern as a whole). + + + + + + This field contains a brief description of the indicator. + + + + + + References the defined environments where this indicator of susceptibility is applicable. + + + + + + + This field contains a unique integer identifier for the indicator. + + + + + + Each indicator has a mandatory type attribute that can be one of the values "Positive," "Negative," or "Inconclusive." For example, a positive indicator of susceptibility to parameter tampering is the existence of parameters in the URL. Although it does not guarantee susceptibility, it indicates a cause for further examination. A negative indicator for the technique of privilege escalation is a lack of credentials and user identifiers in an application. Again, this is not a conclusive measure of resistance to attack, but an indicator that the attack step technique is unlikely to bear significant fruit. An inconclusive indicator of susceptibility to dynamic code injection is a page whose URL ends in .jsp, .asp, or .do but which has no visible explicit parameters. Such URLs typically indicate dynamic processing, but since no visible parameters are passed, it is inconclusive whether dynamic code could be injected into the application. + + + + + + + + + + + + + + + + + + + + This field captures possible outcomes for this attack step. + + + + + + + + + + This field contains a unique integer identifier for the outcome. + + + + + An outcome has a mandatory type attribute that can be one of the values "success," "failure," or "inconclusive." It indicates what results of executing the attack step techniques should be considered successes, which should be considered failures, and which ones are inconclusive. Outcomes' successes are determined relative to the attacker's point of view. It is a success if the attack step got the attacker closer to his goal of attacking the application. It is a failure if the attacker got no closer to his goal. + + + + + + + + + + + + + + + + + + + + This field captures security controls for this attack step that describe ways in which the attack step can be detected, corrected, or prevented. These are presented from a defender's point of view, where the defender may be a developer, tester, operations administrator, or other resource resisting the attacker. + + + + + + + + + + + + + + + + + This field contains a unique integer identifier for the security control. + + + + + Each security control has a mandatory type attribute that can be one of the values "Detective," "Corrective," or "Preventative." Detective controls detect an attacker's activities in the attack step, whether the activities are successful or not. Corrective controls attempt to mitigate an attacker's success by responding to a successful outcome. They are not related to or normalized against outcomes. Preventative controls are those that make the attack step unlikely or impossible to succeed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + This subelement identifies an individual consequence that +may result from this attack pattern. + + + + + + + + + + + + + + + + + + This subelement describes the technical impacts that can result from successful execution of this attack pattern. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + This subelement provides additional commentary about this consequence. + + + + + + The Common_Consequence_ID stores the value for the related +Common_Consequence entry identifier as a string. Only one +Common_Consequence_ID element can exist for each Common_Consequence element +(ex: CC-1). However, Common_Consequences across CAPEC with the same ID should +only vary in small details. + + + + + + + + This field contains a detailed description of the attack including the chain of actions taken by the attacker. More comprehensive descriptions could include relevant attack trees and/or exploit graphs to more clearly elaborate this type of attack. + + + + + + Brief description of what the attack involves and what weaknesses it is leveraging for exploit. + + + + + Outline of the steps involved in an attacker executing the typical flow of the attack. + + + + + + + + This element contains one or more Alternate_Term elements, each ofwhich contains other names used to describe this attack pattern. + + + + + + This field describes the conditions that must exist or the functionality and characteristics that the target software must have or behavior it must exhibit for an attack of this type to succeed. + + + + + + This field describes an individual attack prerequisite. + + + + + + + + On a rough scale (Very Low, Low, Medium, High, Very high), what is the typical severity of impact to the targeted software if this attack occurs? The severity of a specific attack instance can vary greatly depending on the specific context of the target software under attack. This field is intended to capture an overall typical average value for this type of attack with the understanding that it will not be completely accurate for all attacks. + + + + + + + + + + + + + + On a rough scale (Very Low, Low Medium, High, Very High), what is the overall likelihood of this type of attack typically succeeding considering the attack prerequisites, targeted weakness attack surface, skill required and resources required as well as available and likely implemented blocking solutions? The likelihood of exploit of a specific attack instance can vary greatly depending on the specific context of the target software under attack. This field is intended to capture an overall typical average value for this type of attack with the understanding that it will not be completely accurate for all attacks. + + + + + + On a rough scale (Very Low, Low Medium, High, Very High), what is the overall likelihood of this type of attack typically succeeding considering the attack prerequisites, targeted weakness attack surface, skill required and resources required as well as available and likely implemented blocking solutions? + + + + + This field captures any useful explanation for the defined Likelihood. + + + + + + + + This field describes the mechanism of attack used by this pattern. This field can help define the applicable attack surface required for this attack. + + + + + + This field describes the mechanism of attack used by this pattern. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined vectors which is currently incomplete and will grow as new relevant vectors are identified. This field can help define the applicable attack surface required for this attack. + + + + + + + + + + + + + + + + + + + + + + This field contains explanatory examples or demonstrative exploit instances of this attack, which are intended to help the reader understand the nature, context and variability of the attack in more practical and concrete terms. + + + + + + This field describes an individual example or exploit instance. + + + + + + This field describes in detail a specific example or exploit instance of this attack. It should outline the context of the attack, the targeted software, the targeted weaknesses or vulnerabilities, the specific set of actions involved in the attack and the resulting impact of the attacks success or failure (in the case of counterexamples). + + + + + + + + + + + + + + + This field lists the specific vulnerabilities targeted by this exploit instance of the attack. Specific vulnerabilities should reference industry-standard identifiers such as Common Vulnerabilities and Exposures (CVE) numbers and/or US-CERT numbers. + + + + + + + + + + + + + + This field describes the level of skills or specific knowledge required by an attacker to execute this type of attack. + + + + + + This field describes the level of skill or specific knowledge required by an attacker to execute this type of attack. + + + + + + This should be communicated on a rough scale (Low, Medium, High). +For example: +• Low - Basic computer familiarity +• Low - Basic SQL knowledge +• Medium - Moderate scripting and shell experience and ability to disassemble and decompile +• High - Expert knowledge of LINUX kernel +• High - Detailed knowledge of target software development practices and business context (former employee) +• Etc. + + + + + + + + + + + + + This field provides contextual detail for the skill or knowledge level. + + + + + + + + + + + This field describes the resources (CPU cycles, IP addresses, tools, etc.) required by an attacker to effectively execute this type of attack. + + + + + This field describes techniques typically used to probe and reconnoiter a potential target to determine vulnerability and/or to prepare for this type of attack. + + + + + + This field describes an individual probing technique. + + + + + + + + + + + + + + This field describes activities, events, conditions or behaviors that could serve as indicators that an attack of this type is imminent, in progress or has occurred. + + + + + + This field describes an individual indicator/warning. + + + + + + + + + + + + + + This field describes techniques typically used to disguise the fact that an attack of this type is imminent, in progress or has occurred. + + + + + + This field describes an individual obfuscation technique. + + + + + + + + + + + + + + This field describes actions or approaches that can potentially prevent or mitigate the risk of this attack. These solutions and mitigations are targeted to improve the resistance of the target software and thereby reduce the likelihood of the attack's success or to improve the resilience of the target software and thereby reduce the impact of the attack if it is successful. + + + + + + This field describes an individual blocking solution or mitigation. + + + + + + + + What is the attacker trying to achieve by using this attack? This is not the end business/mission goal of the attack within the target context but rather the specific technical result desired that could be leveraged to achieve the end business/mission objective. This information is useful for aligning attack patterns to threat models and for determining which attack patterns are relevant for a given context. + + + + + + What is the attacker trying to achieve by using this attack? This is not the end business/mission goal of the attack within the target context but rather the specific technical result desired that could be leveraged to achieve the end business/mission objective. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined motivations/consequences which is currently incomplete and will grow as new relevant possibilities are identified. This information is useful for aligning attack patterns to threat models and for determining which attack patterns are relevant for a given context. + + + + + + + + This field describes, as precisely as possible, the mechanism and format of an input-driven attack of this type. Injection vectors must take into account the grammar of an attack, the syntax accepted by the system, the position of various fields, and the ranges of data that are acceptable. + + + + + This field describes the code, configuration or other data to be executed or otherwise activated as part of an injection-based attack of this type. + + + + + This field describes the area within the target software that is capable of executing or otherwise activating the payload of an injection-based attack of this type. The activation zone is where the intent of the attacker is put into action. The activation zone may be a command interpreter, some active machine code in a buffer, a client browser, a system API call, etc. + + + + + This field is a description of the impact that the activation of the attack payload for an injection-based attack of this type would typically have on the confidentiality, integrity or availability of the target software. + + + + + + + + + + + Which specific weaknesses does this attack target and leverage? Specific weaknesses (underlying issues that may cause vulnerabilities) reference the industry-standard Common Weakness Enumeration (CWE). This list should include not only those weaknesses that are directly targeted by the attack but also those whose presence can directly increase the likelihood of the attack succeeding or the impact if it does succeed. + + + + + + This field describes an individual related weakness. + + + + + + The CWE_ID is a field that exists for all weaknesses enumerated in the Common Weakness Enumeration (CWE). It is a unique value that allows each weakness to be unambiguously identified. The CWE_ID field for the attack pattern contains the value of the CWE_ID for the specific related weakness. + + + + + This field describes the nature of the relationship between this weakness and the attack pattern. Weaknesses that are specifically targeted by the attack are of type "Targeted". Weaknesses which are not specifically targeted but whose presence may increase the likelihood of the attack succeeding or the impact of the attack if it does succeed are of type "Secondary". + + + + + + + + + + + + + + + + + What specific vulnerabilities does this attack target and leverage? Specific vulnerabilities should reference industry-standard identifiers such as Common Vulnerabilities and Exposures (CVE ) numbers and/or US-CERT numbers. As vulnerabilities are much more specific and localized than weaknesses, it is typically rare that an attack pattern will target specific vulnerabilities. This would most likely occur if they are targeting vulnerabilities in underlying platforms, frameworks, libraries, etc. + + + + + + This field describes an individual related vulnerability. + + + + + + This field uses the unique reference ID for a specific related vulnerability utilizing an industry standard vulnerability listing (e.g., CVE-2006-4192, VU#650769, etc.). + + + + + This field contains a short textual description of the specific related vulnerability taken from the industry standard vulnerability listing. + + + + + + + + + + + This field identifies other attack patterns that are somehow related to, dependent on, typically chained together, etc. with this pattern. + + + + + + This field describes an individual related attack pattern. + + + + + + + + This field identifies specific security requirements that are relevant to this type of attack and are general enough to offer opportunities for reuse. + + + + + + This field describes an individual relevant security requirement. + + + + + + + + This field identifies specific relevant design patterns that are recommended as providing resistance or resilience to this attack, or which are not recommended as they are particularly susceptible to this type of attack. + + + + + + + + + This field describes an individual design pattern that is recommended due to its likelihood of increasing the software's resistance or resiliency to this type of attack. + + + + + + + + + + + This field describes an individual design pattern that is not recommended due to its likelihood of decreasing the software's resistance or resiliency to this type of attack. + + + + + + + + + + + This field identifies specific security patterns that are recommended as providing resistance or resilience to this type of attack. + + + + + + This field describes an individual relevant security pattern. + + + + + + + + This field identifies specific security principles relevant to this attack pattern. The security principles that this field references come from the set available on the Build Security In website. + + + + + + This field describes an individual security principle. + + + + + + + + This field identifies existing security guidelines that are relevant to identifying or mitigating this type of attack. + + + + + + This field describes an individual related guideline. + + + + + + + + This field describes the generalized purposes of the pattern in order to enable the capture of pattern composibility. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined purposes which may be currently incomplete and may grow as new relevant possibilities are identified. + + + + + + This field describes the generalized purpose of the pattern in order to enable the capture of pattern composibility. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined purposes which may be currently incomplete and may grow as new relevant possibilities are identified. + + + + + + + + + + + + + + + + This field characterizes the typical relative impact of this pattern on the confidentiality, integrity and availability of the targeted software. + + + + + + This field describes the typical impact of this pattern on the confidentiality characteristics of the targeted software and related data. + + + + + + + + + + + + This field describes the typical impact of this pattern on the integrity characteristics of the targeted software and related data. + + + + + + + + + + + + This field describes the typical impact of this pattern on the availability characteristics of the targeted software and related data. + + + + + + + + + + + + + + + This field characterizes the technical context where this pattern is applicable. + + + + + + This field outlines the architectural paradigms of target software where the pattern is possible and relevant. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined paradigms which may be currently incomplete and may grow or change as new relevant possibilities are identified. + + + + + + This field outlines the architectural paradigms of target software where the pattern is possible and relevant. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined paradigms which may be currently incomplete and may grow or change as new relevant possibilities are identified. + + + + + + + + + + + + + + + + + + + This field outlines the frameworks used as part of the target software where the pattern is possible and relevant. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined frameworks which may be currently incomplete and may grow or change as new relevant possibilities are identified. + + + + + + This field outlines the frameworks used as part of the target software where the pattern is possible and relevant. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined frameworks which may be currently incomplete and may grow or change as new relevant possibilities are identified. + + + + + + + + + + + + + + + + + + + This field outlines the platforms (OS) of the target software where the pattern is possible and relevant. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined platforms which may be currently incomplete and may grow or change as new relevant possibilities are identified. + + + + + + This field outlines the platforms (OS) of the target software where the pattern is possible and relevant. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined platforms which may be currently incomplete and may grow or change as new relevant possibilities are identified. + + + + + + + + + + + + + + + + + This field outlines the implementation languages of the target software where the pattern is possible and relevant. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined platforms which may be currently incomplete and may grow or change as new relevant possibilities are identified. + + + + + + This field outlines the implementation languages of the target software where the pattern is possible and relevant. In order to assist in normalization and classification, this field involves a selection from an enumerated list of defined platforms which may be currently incomplete and may grow or change as new relevant possibilities are identified. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + This field is intended to be a catch-all field for assisting in searching and subsecting a collection of patterns according to criteria not contained elsewehre in this schema. + + + + + + This field contains an individual keyword to be used for tagging and searching. + + + + + + + + This field enumerates reference resources that were used to develop the definition of this attack pattern and those that could prove valuable to the reader looking for further information on this attack. + + + + + + This field should describe the reference clearly and unambiguously by name and with some method of address such that the reader can locate the resource for further reference. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The Status attribute defines the status level for this view. + + + + + diff --git a/stix_validator/schema/external/cvrf_1.1/common.xsd b/stix_validator/schema/external/cvrf_1.1/common.xsd new file mode 100755 index 0000000..ed9152d --- /dev/null +++ b/stix_validator/schema/external/cvrf_1.1/common.xsd @@ -0,0 +1,176 @@ + + + + + + + + + + + + This is the XML schema for the Common Vulerability Reporting Framework's common data types. + + Brian Schafer <bschafer@microsoft.com> + Joe Clarke <jclarke@cisco.com> + Joe Hemmerlein <Joe.Hemmerlein@microsoft.com> + 2012-05-07 + CVRF Common Data Types + 1.1 + + + + + + + + A normalized string type that cannot be empty. + + + + + + + + A string type that cannot be empty. + + + + + + + + String type with an optional language attribute. The default language is English. + + + + + + Locale code used for the string value. The default is "en". + + + + + + + + Normalized string type with an optional language attribute. The default language is English. This string cannot be empty. + + + + + + Locale code used for the string value. The default is "en". + + + + + + + + Dotted string representing the document revision + + + + + + + + Types enumerating the type of reference document + + + + + This document is an external reference to the current vulnerability. + + + + + This document is a reference to this same vulnerability. + + + + + + + Types enumerating the various publishers of a document. + + + + + Developers or maintainers of information system products or services. + + + + + Individuals or organizations that find vulnerabilities or security weaknesses. + + + + + Individuals or organizations that manage a single vendor's response or multiple vendors' responses to a vulnerability, a security flaw, or an incident. + + + + + Everyone using a vendor's product. + + + + + Catchall for everyone else. Currently this includes forwarders, re-publishers, language translators and miscellaneous contributors. + + + + + + + Allowed type values for CVRF notes. + + + + + A general, high-level note (Title may have more information). + + + + + A low-level detailed discussion (Title may have more information). + + + + + A description of something (Title may have more information). + + + + + A summary of something (Title may have more information). + + + + + A list of frequently asked questions. + + + + + Any possible legal discussion, including constraints, surrounding the document. + + + + + Something that doesn’t fit (Title should have more information). + + + + + diff --git a/stix_validator/schema/external/cvrf_1.1/cpe-language_2.2a.xsd b/stix_validator/schema/external/cvrf_1.1/cpe-language_2.2a.xsd new file mode 100755 index 0000000..a337d06 --- /dev/null +++ b/stix_validator/schema/external/cvrf_1.1/cpe-language_2.2a.xsd @@ -0,0 +1,182 @@ + + + + + This XML Schema defines the CPE Language. An individual + CPE Name addresses a single part of an actual system. To identify more complex + platform types, there needs to be a way to combine different CPE Names using + logical operators. For example, there may be a need to identify a platform with a + particular operating system AND a certain application. The CPE Language exists to + satisfy this need, enabling the CPE Name for the operating system to be combined + with the CPE Name for the application. For more information, consult the CPE + Specification document. + + CPE Language + Neal Ziring, Andrew Buttner, David Waltermire + 2.2 + 10/27/2008 10:00:00 AM + + + + + + + + + This element is the root element of a CPE + Language XML documents and therefore acts as a container for child platform + definitions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The platform element represents the description + or qualifications of a particular IT platform type. The platform is defined + by the logical-test child element. + + + + + The optional title element may appear as a child + to a platform element. It provides a human-readable title for it. To support + uses intended for multiple languages, this element supports the ‘xml:lang’ + attribute. At most one title element can appear for each language. + + + + + The optional remark element may appear as a child + of a platform element. It provides some additional description. Zero or more + remark elements may appear. To support uses intended for multiple languages, + this element supports the ‘xml:lang’ attribute. There can be multiple + remarks for a single language. + + + + + + + + + + + The id attribute holds a locally unique + name for the platform. There is no defined format for this id, it just has + to be unique to the containing language document. + + + + + + + + The logical-test element appears as a child of a + platform element, and may also be nested to create more complex logical + tests. The content consists of one or more elements: fact-ref, and + logical-test children are permitted. The operator to be applied, and + optional negation of the test, are given as attributes. + + + + + + + + + + + + + + + The fact-ref element appears as a + child of a logical-test element. It is simply a reference to a CPE Name that + always evaluates to a Boolean result. + + + + + + + + + + The OperatorEnumeration simple type defines + acceptable operators. Each operator defines how to evaluate multiple + arguments. + + + + + + + + + + + + This type allows the xml:lang attribute to + associate a specific language with an element's string + content. + + + + + + + + + + + + + Define the format for acceptable CPE Names. A URN + format is used with the id starting with the word cpe followed by :/ and + then some number of individual components separated by + colons. + + + + + + + + + + diff --git a/stix_validator/schema/external/cvrf_1.1/cvrf.xsd b/stix_validator/schema/external/cvrf_1.1/cvrf.xsd new file mode 100755 index 0000000..3448717 --- /dev/null +++ b/stix_validator/schema/external/cvrf_1.1/cvrf.xsd @@ -0,0 +1,487 @@ + + + + + + + + + + + + + + This is the XML schema for the Common Vulnerability Reporting Framework. For more information, see the CVRF whitepaper. + + Brian Schafer <bschafer@microsoft.com> + Joe Clarke <jclarke@cisco.com> + Joe Hemmerlein <Joe.Hemmerlein@microsoft.com> + 2012-05-07 + CVRF Dictionary + 1.1 + + + + + + + + Types enumerating the status of the document. + + + + + Pre-release, intended for issuing party’s internal use only, or possibly used externally when the party is seeking feedback or indicating its intentions regarding a specific issue. + + + + + The issuing party believes the content is subject to change. + + + + + The issuing party asserts the content is unlikely to change. + + + + + + + Floating point number representing the CVRF specification version + + + + + + + + + + + Root element of a CVRF document. + + + + + + A definitive canonical name for the document, providing enough descriptive content to differentiate from other similar documents, ideally providing a unique “handle”. + + + + + + + + + + A short canonical name, chosen by the document producer, which will inform the consumer about the type of the document. + + + + + + + + + + A container holding all information about the publisher of the CVRF document. + + + + + + Author contact information such as address, phone number, email, etc. + + + + + + + + + + The name of the issuing party and their authority to release the document, in particular, the party's constituency and responsibilities or other obligations. + + + + + + + + + + + Type is an enumerated list containing an array of different document publisher types. + + + + + Vendor ID is a unique identifier (OID) that a vendor uses as issued by FIRST under the auspices of IETF. + + + + + + + The Document Tracking meta-container contains all of the attributes necessary to track a CVRF document. + + + + + + Contains document ID and optional document aliases + + + + + + Short unique identifier used to refer to the document unambiguously in any context. + + + + + + + + + + Optional alternative ID for document + + + + + + + + + + + + + The condition of the document with regard to completeness and the likelihood of future editions. + + + + + Document Version is a simple counter to track the version of the document. + + + + + The Document Revision History contains one entry for each substantive version of the document, including the initial version and entries for each subsequent update. + + + + + + A set of Version, Date, and Description elements describing one iteration of this document + + + + + + Revision number of this iteration of the document. + + + + + Date when this iteration of the document was released. + + + + + Description of this iteration of the document. + + + + + + + + + + + + + + + + The initial date (and time, optionally) that the document was initially released by the issuing party. + + + + + The current date (and time, optionally) that the document was released by the issuing party. + + + + + The Document Generator meta-container contains all of the elements related to the generation of the document. + + + + + + The name and version of the engine that generated the CVRF document. + + + + + + + + + + The date the CVRF document was generated. + + + + + + + + + + + The Document Notes text contains all of the individual notes necessary to provide different types of low-level discussions of a CVRF document to various audiences. + + + + + + A individual note in freeform text. + + + + + + + Title should be a concise description of what is contained in this specific note. + + + + + Audience will indicate who is intended to read the note. + + + + + Type of content within this note. + + + + + Ordinal is a locally significant integral counter indexed from 1 used to track notes. + + + + + + + + + + + + The Document Distribution string should contain details on constraints, if any, about sharing this CVRF Document with additional recipients. + + + + + + + + + + Aggregate Severity is provided by the producer of the document to convey the urgency and criticality with which the vulnerability or vulnerabilities should be addressed. + + + + + + + URL of the namespace from which the Aggregate Severity is taken. + + + + + + + + + This meta-container should include references to any conferences, papers, advisories, and other resources that are related and considered to be of value to the document consumer. + + + + + + Related documents to the CVRF document. + + + + + + The URL of the related document. + + + + + The description of the related document. + + + + + + + + + + + Enumerated type value of reference relative to this document. + + + + + + + + + + The Acknowledgments container holds one or more Acknowledgement containers for document-level acknowledgements. + + + + + + The Acknowledgment container holds recognition details for external parties, specific to the document as a whole rather than individual vulnerabilities. + + + + + + The name (i.e., individual name) of the party being acknowledged. + + + + + + + + + + The organization of the party being acknowledged or the organization itself being acknowledged. + + + + + + + + + + The details of the acknowledgment that address the recognition of external parties who were instrumental in the discovery, reporting and response of this document. + + + + + + + + + + The optional URL to the person, place, or thing being acknowledged. + + + + + + + + + + + + + + + This is to ensure that each Vulnerability's Ordinal uses a unique value. + + + + + + + This is to ensure that each note has a unique ordinal value. + + + + + + + A key to reference a specific product defined in a referenced product schema. + + + + + + + An instance of the ProductKey to be used in the ProductID element for affected products. + + + + + + + An instance of the ProductKey to be used in the CVSS ScoreSet product references. + + + + + + + An instance of the ProductKey to be used in the Threat product references. + + + + + + + An instance of the ProductKey to be used in the Remediation product references. + + + + + + + A key to reference a specific product group defined in a referenced product schema. + + + + + + + An instance of the GroupKey to be used in the Threat product references. + + + + + + + An instance of the GroupKey to be used in the Remediation product references. + + + + + + diff --git a/stix_validator/schema/external/cvrf_1.1/cvss-v2_0.9.xsd b/stix_validator/schema/external/cvrf_1.1/cvss-v2_0.9.xsd new file mode 100755 index 0000000..f68fb81 --- /dev/null +++ b/stix_validator/schema/external/cvrf_1.1/cvss-v2_0.9.xsd @@ -0,0 +1,415 @@ + + + + + + + + + + + + Value restriction to single decimal values from 0.0 to 10.0, as used in CVSS scores + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Indicates if the vector has been approximated as the result of an upgrade from a previous CVSS version + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + "This schema was intentionally designed to avoid mixing classes and attributes between CVSS version 1, CVSS version 2, and future versions. Scores in the CVSS system are interdependent. The temporal score is a multiplier of the base score. The environmental score, in turn, is a multiplier of the temporal score. The ability to transfer these scores independently is provided on the assumption that the user understands the business logic. For any given metric, it is preferred that the score, as a minimum is provided, however the score can be re-created from the metrics or the multiplier and any scores they are dependent on." + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Base type for metrics that defines common attributes of all metrics. + + + + Indicates if the metrics have been upgraded from a previous version of CVSS. If fields that were approximated will have an approximated attribute set to 'true'. + + + + + + + + + + + + + Base severity score assigned to a vulnerability by a source + + + + + Base exploit sub-score assigned to a vulnerability by a source + + + + + Base impact sub-score assigned to a vulnerability by a source + + + + + + Data source the vector was obtained from. Example: http://nvd.nist.gov or com.symantec.deepsight + + + + + + + + + + + + + + + + + + + Data source the vector was obtained from. Example: gov.nist.nvd or com.symantec.deepsight + + + + + + + + + + + + + + + + + The temporal score is the temporal multiplier times the base score. + + + + + The temporal multiplier is a number between zero and one. Reference the CVSS standard for computation. + + + + + + + + + + diff --git a/stix_validator/schema/external/cvrf_1.1/dc.xsd b/stix_validator/schema/external/cvrf_1.1/dc.xsd new file mode 100755 index 0000000..9752962 --- /dev/null +++ b/stix_validator/schema/external/cvrf_1.1/dc.xsd @@ -0,0 +1,118 @@ + + + + + + DCMES 1.1 XML Schema + XML Schema for http://purl.org/dc/elements/1.1/ namespace + + Created 2008-02-11 + + Created by + + Tim Cole (t-cole3@uiuc.edu) + Tom Habing (thabing@uiuc.edu) + Jane Hunter (jane@dstc.edu.au) + Pete Johnston (p.johnston@ukoln.ac.uk), + Carl Lagoze (lagoze@cs.cornell.edu) + + This schema declares XML elements for the 15 DC elements from the + http://purl.org/dc/elements/1.1/ namespace. + + It defines a complexType SimpleLiteral which permits mixed content + and makes the xml:lang attribute available. It disallows child elements by + use of minOcccurs/maxOccurs. + + However, this complexType does permit the derivation of other complexTypes + which would permit child elements. + + All elements are declared as substitutable for the abstract element any, + which means that the default type for all elements is dc:SimpleLiteral. + + + + + + + + + + + + + This is the default type for all of the DC elements. + It permits text content only with optional + xml:lang attribute. + Text is allowed because mixed="true", but sub-elements + are disallowed because minOccurs="0" and maxOccurs="0" + are on the xs:any tag. + + This complexType allows for restriction or extension permitting + child elements. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + This group is included as a convenience for schema authors + who need to refer to all the elements in the + http://purl.org/dc/elements/1.1/ namespace. + + + + + + + + + + + + + + This complexType is included as a convenience for schema authors who need to define a root + or container element for all of the DC elements. + + + + + + + + + + diff --git a/stix_validator/schema/external/cvrf_1.1/prod.xsd b/stix_validator/schema/external/cvrf_1.1/prod.xsd new file mode 100755 index 0000000..99fccad --- /dev/null +++ b/stix_validator/schema/external/cvrf_1.1/prod.xsd @@ -0,0 +1,292 @@ + + + + + + + + + + + + + + + This is the XML schema for the Common Vulnerability Reporting Framework's Product model. For more information, see the CVRF whitepaper. + + Joe Hemmerlein <joe.hemmerlein@microsoft.com> + Joe Clarke <jclarke@cisco.com> + 2012-05-07 + CVRF Product Dictionary + 1.1 + + + + + + + + Types enumerating the individual parts (stubs) that comprise a product name. + + + + + The name of the vendor or manufacturer that makes the product . + + + + + The product family that the product falls into. + + + + + The name of the product. + + + + + The version of the product. This can be a numeric or other descriptor. + + + + + The patch level of the product. + + + + + The service pack of the product. + + + + + The architecture for which the product is intended. + + + + + The language of the product. + + + + + A non-specific legacy entry. + + + + + A specification such as a standard, best common practice, etc. + + + + + The host name of a system/service. + + + + + The URI component of a system/service. + + + + + The file name component of a system/service. + + + + + + + Types enumerating the ways products can be related to each other. + + + + + This product is a default component of the referenced product. + + + + + This product is an optional component of the referenced product. + + + + + This product is an external component of the referenced product. + + + + + This product is installed on the referenced product. + + + + + This product is installed with the referenced product. + + + + + + + + + + + + + + + + + + Neutral product tree to streamline product entries that can be referenced elsewhere in the document. The end of each branch ("FullProductName") represents a referrenceable product. + + + + + + + + Defines how this product is related to another product. + + + + + + + + The ProductReference refers to the unique ProductID of the product that is to which another product will be related. + + + + + The RelationType attribute defines how the two products are related. + + + + + RelatesToProductReference refers to the unique ProductID of the product to which the ProductReference attribute value relates. + + + + + + + Container for grouping products to be used in vulnerabilities. + + + + + + A named container to associate two or more product IDs together for use in vulnerabilities. + + + + + + Optional textual description for this group. + + + + + + + + + + The ID of an existing product in this tree that is to be a member of this group. + + + + + + The unique identifier used to reference this group. + + + + + + + + + + + + This is to ensure that each FullProductName uses a unique ProductID value. + + + + + + + This is to ensure that each Group uses a unique GroupID value. + + + + + + + A key to reference a specific product. + + + + + + + An instance of the ProductKey used to define a relationship product. + + + + + + + An instance of the ProductKey used to define a related product. + + + + + + + An instance of the ProductKey used to define a product group membership list. + + + + + + + + Endpoint of product tree - this is an actual product entry. The string represents the friendly product name (i.e. the way it would be printed in other publications) + + + + + + + A value that uniquely identifies this Product entry in the scope of this document. Whenever a reference to this Product entry is needed anywhere in this document, its unique ID will be referenced. + + + + + The Common Platform Enumeration (CPE) attribute refers to a method for naming platforms. The structure for CPE is described at http://cpe.mitre.org. + + + + + + + diff --git a/stix_validator/schema/external/cvrf_1.1/scap-core_0.9.xsd b/stix_validator/schema/external/cvrf_1.1/scap-core_0.9.xsd new file mode 100755 index 0000000..e274dcb --- /dev/null +++ b/stix_validator/schema/external/cvrf_1.1/scap-core_0.9.xsd @@ -0,0 +1,170 @@ + + + + + + + + + + + + + + + Data type for the check element, a checking system specification URI, string content, and an optional external file reference. The checking system specification should be the URI for a particular version of OVAL or a related system testing language, and the content will be an identifier of a test written in that language. The external file reference could be used to point to the file in which the content test identifier is defined. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Denotes a scanner and required configuration that is capable of detecting the referenced vulnerability. May also be an OVAL definition and omit scanner name. + Identifies a tool and any associated information about the tool, such as signature versions, that indicate the tool is capable or properly detecting and/or remdiating the vulnerability or misconfiguration + + + + + Identifies a check that can be used to detect the vulnerability or misconfiguration + + + + + The CPE name of the scanning tool. A value must be supplied for this element. The CPE name can be used for a CPE from the NVD. The CPE title attribute can be used for internal naming conventions. (or both, if possible) + + + + + + + + + + + + + + + + + + + + Define the format for acceptable CPE Names. An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'def', and ending with an integer. + + + + + + + + + Define the format for acceptable CPE Names. A URN format is used with the id starting with the word cpe followed by :/ and then some number of individual components separated by colons. + + + + + + + + + Define the format for acceptable + searchableCPE Names. The URI escaped code '%25' may be used + to represent the character '%' which will be interpreted as a + wildcard. + + + + + + + + + The name pattern of a CPE component. + + + + + + + + + The name pattern of the CPE part component. + + + + + + + + + + + + + + + + diff --git a/stix_validator/schema/external/cvrf_1.1/vuln.xsd b/stix_validator/schema/external/cvrf_1.1/vuln.xsd new file mode 100755 index 0000000..fc090c2 --- /dev/null +++ b/stix_validator/schema/external/cvrf_1.1/vuln.xsd @@ -0,0 +1,631 @@ + + + + + + + + + + + + + + + + This is the XML schema for the Common Vulnerability Reporting Framework's Vulnerability model. For more information, see the CVRF whitepaper. + + Brian Schafer <bschafer@microsoft.com> + Joe Clarke <jclarke@cisco.com> + Joe Hemmerlein <Joe.Hemmerlein@microsoft.com> + 2012-05-07 + CVRF Vulnerability Dictionary + 1.1 + + + + + + + + Types enumerating a party's current engagement status for this vulnerability. + + + + + The party has acknowledged that they are aware of the vulnerability report. + + + + + The party disputes the vulnerability report in its entirety + + + + + Some hot-fixes, permanent fixes, or patches have been made available by the party, but more fixes or patches are going to be released in the future. + + + + + The party asserts that they have completed remediation of the vulnerability. + + + + + The party has been contacted, but was unresponsive or unavailable. + + + + + No contact has been attempted with the party. + + + + + + + String type to match CVE IDs + + + + + + + + String type to match CWE IDs + + + + + + + + String representing the components needed to compute the various CVSS scores + + + + + + + + Types enumerating the affected statuses described by a vulnerability + + + + + The first version known to be affected by this vulnerability. + + + + + This version is the first fixed version for the vulnerability but may not be the recommended fixed version. + + + + + This version is contains a fix for the vulnerability but may not be the recommended fixed version. + + + + + This version is known to be affected by the vulnerability. + + + + + This version is known NOT to be affected by the vulnerability. + + + + + This is the last version in a train known to be affected. Versions released after this would contain a fix for this vulnerability. + + + + + This version has a fix for the vulnerability and is the vendor-recommended version for fixing the vulnerability. + + + + + + + Types enumerating the Threat type described by the vulnerability + + + + + Impact contains an assessment of the impact on the user or the target set if the vulnerability is successful exploited. + + + + + Exploit Status contains a description of the degree to which an exploit for the vulnerability is known. + + + + + Target Set contains a description of the currently known victim population in whatever terms are appropriate. + + + + + + + Types enumerating the Remedy type described by the vulnerability. + + + + + Workaround contains information about a configuration or specific deployment scenario that can be used to avoid exposure to the vulnerability. + + + + + Mitigation contains information about a configuration or deployment scenario that helps to reduce the risk of the vulnerability but that does not resolve the vulnerability on the affected product. + + + + + Vendor Fix contains information about an official fix that is issued by the original author of the affected product. + + + + + Currently there is no fix available. + + + + + There is no fix for the vulnerability and there never will be one. + + + + + + + Existing product ID from the product tree. + + + + + Existing product group ID from the product tree. + + + + + + + + This is a meta-container for the aggregation of all fields that are related to a single vulnerability within the document. + + + + + + Vulnerability Title gives the document producer the ability to apply a canonical name or title to the vulnerability. + + + + + + + + + + Vulnerability ID gives the document producer a place to publish a unique label or tracking ID for the vulnerability (if such information exists). + + + + + + + System Name indicates the name of the vulnerability tracking or numbering system that this vulnerability ID comes from. + + + + + + + + + The Notes container holds all individual notes concerning this vulnerability. + + + + + + The Notes text contains all of the content necessary to provide different types of low-level discussions of a given vulnerability to various audiences. + + + + + + + Title should be a concise description of what is contained in Vulnerability Notes. + + + + + Audience will indicate who is intended to read the note. + + + + + Type of content within this note. + + + + + Ordinal is a locally significant integral counter indexed from 1 used to track notes. + + + + + + + + + + + + Date vulnerability was initially discovered by its original discoverer. + + + + + Date vulnerability was initially released to the public. + + + + + The Involvements container lists any number of vendor or third party interactions related to this vulnerability. + + + + + + Involvement contains a specific set of interaction details. + + + + + + The description of the Involvement. + + + + + + + + + + + Type of party with whom the involvement is taking place. + + + + + Status of the involvement with the specified party. + + + + + + + + + + The CVE string refers to the MITRE standard Common Vulnerabilities Enumeration (CVE) tracking number for the vulnerability. + + + + + Detailed description of the referrenced Common Weakness Enumeration (CWE) identifier. + + + + + + + The MITRE-assigned CWE identifier. + + + + + + + + + The ProductStatuses container holds the list of all the products affected by the vulnerability in question. + + + + + + The Status element holds an enumerated value based on available Product Name Entry items as constructed from the Product Tree container. + + + + + + + + Affected status for the product or products defined in this container. + + + + + + + + + + Contains all Threat containers + + + + + + Threat contains the "kinetic" information associated with a vulnerability. + + + + + + The description of the Threat. + + + + + + + + + + + + + The type of the Threat. + + + + + The date this Threat item was last updated; if omitted it is deemed to be unknown, irrelevant, or unimportant. + + + + + + + + + + The CVSS Score Set meta-container holds one or more CVSS score sets to describe vulnerable products. + + + + + + CVSS scores for a given product ID.  If the ProductID attribute is omitted, the score applies to all vulnerable products. + + + + + + The CVSS Base Score is the numeric value of the computed CVSS Base Score which should be a float from 0 – 10.0. + + + + + The CVSS Base Score is the numeric value of the computed CVSS Temporal Score which should be a float from 0 – 10.0. + + + + + The CVSS Base Score is the numeric value of the computed CVSS Environmental Score which should be a float from 0 – 10.0. + + + + + The CVSS Vector string is the official notation that contains all of the values used to compute the Base, Temporal, and Environmental scores. + + + + + + + + + + + + The Remediation meta-container tag holds all related Workaround, Mitigation, Vendor Fix, and Entitlement entries that are associated with the specific vulnerability. + + + + + + Holds all of the specific details on how to handle (and presumably, fix) the vulnerability, tied to Product ID. + + + + + + Textual description of this remedy. + + + + + + + + + + The Entitlement string will contain any possible vendor-defined constraints for obtaining fixed software or hardware that fully resolves the vulnerability. + + + + + + + + + + URL from which the remedy can be obtained. + + + + + + + + Specific type of remedy. + + + + + The date Remedy was last updated, if omitted it is deemed to be unknown, unimportant, or irrelevant. + + + + + + + + + + This meta-container should include references to any conferences, papers, advisories, and other resources that are related to this vulnerability. + + + + + + This meta-container contains an orthogonally related document, background info, whitepaper, etc. to the specific vulnerability. + + + + + + The URL of the related document. + + + + + The description of the related document. + + + + + + + + + + + Enumerated type value of reference relative to this document. + + + + + + + + + + The Acknowledgments container holds one or more Acknowledgement containers for vulnerability-level acknowledgements. + + + + + + The Acknowledgment container holds recognition for external parties who were instrumental in the discovery of, reporting of, and response to the vulnerability. + + + + + + The name (i.e., individual name) of the party being acknowledged. + + + + + + + + + + The organization of the party being acknowledged or the organization itself being acknowledged. + + + + + + + + + + The details of the acknowledgment that address the recognition of external parties who were instrumental in the discovery, reporting and response of this document. + + + + + + + + + + The optional URL to the person, place, or thing being acknowledged. + + + + + + + + + + + + Locally significant numeric value to track vulnerabilities within a CVRF document. This enables vulnerabilities to be referenced from elsewhere inside the document (often at the document-level) + + + + + + This is to ensure that each product mentions a given ProductID only one. + + + + + + + This is to ensure that each CVSS score set mentions a given ProductID only one. + + + + + + + This is to ensure that each note has a unique ordinal value. + + + + + + diff --git a/stix_validator/schema/external/cvrf_1.1/xml.xsd b/stix_validator/schema/external/cvrf_1.1/xml.xsd new file mode 100755 index 0000000..aea7d0d --- /dev/null +++ b/stix_validator/schema/external/cvrf_1.1/xml.xsd @@ -0,0 +1,287 @@ + + + + + + +
+

About the XML namespace

+ +
+

+ This schema document describes the XML namespace, in a form + suitable for import by other schema documents. +

+

+ See + http://www.w3.org/XML/1998/namespace.html and + + http://www.w3.org/TR/REC-xml for information + about this namespace. +

+

+ Note that local names in this namespace are intended to be + defined only by the World Wide Web Consortium or its subgroups. + The names currently defined in this namespace are listed below. + They should not be used with conflicting semantics by any Working + Group, specification, or document instance. +

+

+ See further below in this document for more information about how to refer to this schema document from your own + XSD schema documents and about the + namespace-versioning policy governing this schema document. +

+
+
+ + + + + + +
+ +

lang (as an attribute name)

+

+ denotes an attribute whose value + is a language code for the natural language of the content of + any element; its value is inherited. This name is reserved + by virtue of its definition in the XML specification.

+ +
+
+

Notes

+

+ Attempting to install the relevant ISO 2- and 3-letter + codes as the enumerated possible values is probably never + going to be a realistic possibility. +

+

+ See BCP 47 at + http://www.rfc-editor.org/rfc/bcp/bcp47.txt + and the IANA language subtag registry at + + http://www.iana.org/assignments/language-subtag-registry + for further information. +

+

+ The union allows for the 'un-declaration' of xml:lang with + the empty string. +

+
+ + + + + + + + + + + + + + + + +
+ +

space (as an attribute name)

+

+ denotes an attribute whose + value is a keyword indicating what whitespace processing + discipline is intended for the content of the element; its + value is inherited. This name is reserved by virtue of its + definition in the XML specification.

+ +
+ + + + + + + + + + + + +
+ +

base (as an attribute name)

+

+ denotes an attribute whose value + provides a URI to be used as the base for interpreting any + relative URIs in the scope of the element on which it + appears; its value is inherited. This name is reserved + by virtue of its definition in the XML Base specification.

+ +

+ See http://www.w3.org/TR/xmlbase/ + for information about this attribute. +

+
+ + + + + + + +
+ +

id (as an attribute name)

+

+ denotes an attribute whose value + should be interpreted as if declared to be of type ID. + This name is reserved by virtue of its definition in the + xml:id specification.

+ +

+ See http://www.w3.org/TR/xml-id/ + for information about this attribute. +

+
+ + + + + + + + + + + + + +
+ +

Father (in any context at all)

+ +
+

+ denotes Jon Bosak, the chair of + the original XML Working Group. This name is reserved by + the following decision of the W3C XML Plenary and + XML Coordination groups: +

+
+

+ In appreciation for his vision, leadership and + dedication the W3C XML Plenary on this 10th day of + February, 2000, reserves for Jon Bosak in perpetuity + the XML name "xml:Father". +

+
+
+
+ + + + + +
+

About this schema document

+ +
+

+ This schema defines attributes and an attribute group suitable + for use by schemas wishing to allow xml:base, + xml:lang, xml:space or + xml:id attributes on elements they define. +

+

+ To enable this, such a schema must import this schema for + the XML namespace, e.g. as follows: +

+ 
+          <schema . . .>
+           . . .
+           <import namespace="http://www.w3.org/XML/1998/namespace"
+                      schemaLocation="http://www.w3.org/2001/xml.xsd"/>
+
+

+ or +

+ 
+           <import namespace="http://www.w3.org/XML/1998/namespace"
+                      schemaLocation="http://www.w3.org/2009/01/xml.xsd"/>
+
+

+ Subsequently, qualified reference to any of the attributes or the + group defined below will have the desired effect, e.g. +

+ 
+          <type . . .>
+           . . .
+           <attributeGroup ref="xml:specialAttrs"/>
+
+

+ will define a type which will schema-validate an instance element + with any of those attributes. +

+
+
+ + + + + +
+

Versioning policy for this schema document

+
+

+ In keeping with the XML Schema WG's standard versioning + policy, this schema document will persist at + + http://www.w3.org/2009/01/xml.xsd. +

+

+ At the date of issue it can also be found at + + http://www.w3.org/2001/xml.xsd. +

+

+ The schema document at that URI may however change in the future, + in order to remain compatible with the latest version of XML + Schema itself, or with the XML namespace itself. In other words, + if the XML Schema or XML namespaces change, the version of this + document at + http://www.w3.org/2001/xml.xsd + + will change accordingly; the version at + + http://www.w3.org/2009/01/xml.xsd + + will not change. +

+

+ Previous dated (and unchanging) versions of this schema + document are at: +

+ +
+
+ + + + + diff --git a/stix_validator/schema/external/oasis_ciq_3.0/CommonTypes.xsd b/stix_validator/schema/external/oasis_ciq_3.0/CommonTypes.xsd new file mode 100755 index 0000000..bfe3cd1 --- /dev/null +++ b/stix_validator/schema/external/oasis_ciq_3.0/CommonTypes.xsd @@ -0,0 +1,104 @@ + + + + + Specification Name: OASIS CIQ TC - CIQ V3.0 + Description: Defines the W3C schema with commonly used types in the name, address and party schemas + (Using XML Schema based standard code list/enumeration mechanism - OPTION 1 AND DEFAULT) + Produced by: OASIS Customer Information Quality Technical Committee + URL: http://www.oasis-open.org/committees/ciq + Version: 3.0 + Status: Committee Specification CS02 + Copyright: 2007-09, OASIS, http://www.oasis-open.org + Last Modified: 20 September 2008 + Last Modified by: Ram Kumar, Chair, OASIS CIQ TC + + Please note: These schemas have been modified by the STIX team to support remote validation. The only change made is to the schemaLocation attribute(s). + + + + Normalized and Collapsed String + + + + + + + + A list of values to indicate the level of reliability of the data + + + + + The data was validated and is considered to be true and correct. + + + + + Indicates that at least some part of the content is known to be incorrect. + + + + + + + A list of values to indicate the status of the entity + + + + + + Date Valid from to Date Valid to + + + + Could be start date, issue date, validity start date, etc + + + + + Could be end date, expiry date, validity end date, etc + + + + + + A group of commonly used attributes for internal reuse + + + + If set to true then indicates that the value is an abbreviation or initial. If set to false then the value is definitely not an abbreviation. If omitted then it is not known if the value is an abbreviation or not. + + + + + + A group of commonly used attributes for internal reuse + + + + This attribute indicates what level of trust can be given to the parent element. Omit this attribute if the data quality is unknown. If the data quality is known, the value is "Valid, else "InValid" + + + + + Date the data quality is valid from + + + + + Date the data quality is valid to + + + + + + The language used (name of human language, e.g. en, en-US) + + + + Human Language used. e.g. "en", "en-US", "en-AUS", etc + + + + diff --git a/stix_validator/schema/external/oasis_ciq_3.0/xAL-types.xsd b/stix_validator/schema/external/oasis_ciq_3.0/xAL-types.xsd new file mode 100755 index 0000000..eadc5c3 --- /dev/null +++ b/stix_validator/schema/external/oasis_ciq_3.0/xAL-types.xsd @@ -0,0 +1,511 @@ + + + + + Specification Name: OASIS CIQ TC - extensible AddressLanguage Types (xAL-types) + Description: Defines the W3C schema that provides enumeration lists to support xNL v3.0 + (Using XML Schema based standard code list/enumeration mechanism - OPTION 1 AND DEFAULT) + Produced by: OASIS Customer Information Quality Technical Committee + URL: http://www.oasis-open.org/committees/ciq + Version: 3.0 + Status: Committee Specification CS02 + Copyright: 2007-09, OASIS, http://www.oasis-open.org + Last Modified: 20 September 2008 + Last Modified by: Ram Kumar, Chair, OASIS CIQ TC + + NOTE: This is the schema that users can customise the enumeration lists to meet their + exchange requirements. The enumeration values provided are ONLY SAMPLES and + is not complete. It is upto the application to decide what the values should be. To achieve + interoperability between applications using this specification, it is recommended that an + SLA/agreement is in place as to what the enumeration values will be used in this file + + Please note: These schemas have been modified by the STIX team to support remote validation. The only change made is to the schemaLocation attribute(s). + + + + A list of types of addresses + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A list of types of address identiifers + + + + + + A list of ypes of address line., e.g. street details, locality details + + + + + + A list of types of usage of the address + + + + + + + + + + + + + + + A list of administrative area types + + + + + Only name of the administrative area without its type, e.g. NSW, CA, Quebec + + + + + The type of the area, e.g. state, district, province, etc. + + + + + + + + + A list of administrative area name element types + + + + + Name of the administrative area + + + + + + Reference location information in support of the administrative area. e.g. Territory of France + + + + + Other supporting information + + + + + + + A list of codes for name of administrative area + + + + + + A list of country name element types + + + + + Name of the country e.g. AUSTRALIA + + + + + Although a Country, could be classified as a territory of a country. For example, "NOUVELLE CALEDONIE" is a territory of "FRANCE". + + + + + + + A list of codes for name of country + + + + + + A list of codes for datum + + + + + + A list of codes for mode of delivery of address + + + + + + A list of directions for geo-coordinates + + + + + + + + + + + A list of name types for commonly used Number type + + + + + Applicable to mail box office names such as PO BOX, GPO BOX, MAIL BAG NO., etc. + + + + + Indicates that the element contains the lower value of a range, e.g. 25 in 25-37 + + + + + Indicates that the value is a range, e.g. 25-37 + + + + + Indicates that the element contains the top value of a range, e.g. 25 in 25-37 + + + + + Indocates that the element contains some value that is important, but not exactly the number itself. E.g. PoBox can be a prefix in PoBox 2020, street no. A-15, where A is the prefix and 15 is the number + + + + + Indicates that the element contains some value that is important, but not exactly the number itself. E.g. 'bis' in '45 bis' + + + + + Indicates that the value is number, e.g. 2020 in PoBox 2020. The actual value can be alpha-numeric. + + + + + Indicates that the value is a separator that is expected to be preserved. Examples are / - #, as in 15-A where "-" is the separator + + + + + Indicates that the value is an extension number of some identifier, e.g. 01 in Private Bag 2330-01, where the main number of the private bag is 2330, 12345-1223 in post code where 1223 is the extension + + + + + + + A list of locality name element types such as name of locality, reference data in support of locality + + + + + Name of the locality + + + + + + Any reference locality data in support of the locality. e.g. Next town north of Town A, via-town name + + + + + Other supporting information + + + + + + + A list of codes for name of locality + + + + + + A list of locality name types such as Municipality, Village, Area, etc + + + + + + + + + + + + + + + A list of meridian codes + + + + + + A list of types of postal delivery offices + + + + + + A list of postal delivery point types + + + + + + + + + + + + + A list of codes for projection + + + + + + A list of name types for premises + + + + + Names of Premises such as airport, hospital, university, military base, etc. Can also be the name of the building or house or apartment + + + + + Where in the building/landmark the premises is located, e.g. lobby, ground floor, penthouse, or where in a larger complex (e.g. airport) the address is located. + + + + + Free text description that is required to logically connect the 2 premises + + + + + Roads and streets within boundaries of larger complexes/premises such as hospitals, airports, etc. + + + + + Free text description of some other location and how this premises relates to it, e.g. 300m from water station, new the police station, etc. + + + + + additional supporting information + + + + + + + A list of premises type + + + + + + + + + + + + + + + + + + + + A list of rural delivery types such as road, air, water + + + + + + A list of sub administrative area name element types + + + + + Name of the sub administrative area + + + + + + Reference location information in support of the sub administrative area. + + + + + Other supporting information + + + + + + + A list of codes for name of sub adiministrative area + + + + + + A list of sub administrative area name types + + + + + + + + + + + A list of sub locality name element types + + + + + + + + Other supporting information + + + + + + + A list of codes for names of sub locality + + + + + + A ist of sublocality types + + + + + + + + + A list of sub premises types + + + + + + + + + + + + + A list of name element types for thoroughfare + + + + + Just the name part, such as Baker in Baker Street. + + + + + North Archer Street, where "North" is PreDirection + + + + + Archer Street North, where "North" is PostDirection + + + + + This value indicates that the element contains the street name and street number. E.g. 39 Baker Street. Use this when you do not want to break the thoroughfare into atomic types + + + + + Baker Street, where Baker is Name and Street is Type + + + + + 21 Archer Street (Full thoroughfare details) + + + + + Full details of a thorughfare in a single line (unstructured) +e.g. 39 Baker Street North + + + + + When more than one street name is required to identify the location this type can be used to connect them with values such as CORNER OF or VIA. + + + + + Free text description of some other location and how this thoroughfare relates to it, e.g. 300m from water station, new the police station, etc. + + + + + Additional description like intersection, cross streets, etc + + + + + + + A list of types for thoroughfare (e.g. STREET, ROAD, CRT) + + + + diff --git a/stix_validator/schema/external/oasis_ciq_3.0/xAL.xsd b/stix_validator/schema/external/oasis_ciq_3.0/xAL.xsd new file mode 100755 index 0000000..bbbf55b --- /dev/null +++ b/stix_validator/schema/external/oasis_ciq_3.0/xAL.xsd @@ -0,0 +1,672 @@ + + + + + Specification Name: OASIS CIQ TC - extensible Address Language (xAL) + Description: Defines the W3C schema for representing addresses + (Using XML Schema based standard code list/enumeration mechanism - OPTION 1 AND DEFAULT) + Produced by: OASIS Customer Information Quality Technical Committee + URL: http://www.oasis-open.org/committees/ciq + Version: 3.0 + Status: Committee Specification CS02 + Copyright: 2007-09, OASIS, http://www.oasis-open.org + Last Modified: 20 September 2008 + Last Modified by: Ram Kumar, Chair, OASIS CIQ TC + NOTE: Do not modify this schema as it will break specifications compatibility + + Please note: These schemas have been modified by the STIX team to support remote validation. The only change made is to the schemaLocation attribute(s). + + + + + + + Top level element for address with geocode details + + + + + Complex type that defines the structure of an address with geocode details for reuse + + + + + Container for free text address elements where address elements are not parsed + + + + + + Free format address representation. An address can have more than one line. The order of the AddressLine elements must be preserved. + + + + + + + What does the address line describe? e.g. Street details, suburb details, post code details, whole address, etc + + + + + + + + + + + + + + + + Country details + + + + + + + + + + Details of the top-level area division in the country, such as state, district, province, island, region, etc. Note that some countries do not have this + + + + + + Data associated with the Administrative Area. e.g. Full name of administrative area or part of it. eg. MI in USA, NSW in Australia, reference location to the administrative area + + + + + + + + semantics of data associated with name + + + + + Name of administrative area represented as a code. e.g. "COL" for COLORADO + + + + + Type of code used to represent name as a code + + + + + + + + + + The next level down division of the area. E.g. state / county, province / reservation. Note that not all countries have a subadministrative area + + + + + + Data associated with the SubAdministrative Area. e.g. Full name of sub administrative area or part of it. + + + + + + + + semantics of data associated with name + + + + + Name of administrative area represented as a code. e.g. "COL" for COLORADO + + + + + Type of code used to represent name as a code + + + + + + + + + + + Type of sub administrative area + + + + + + + + + + Type of administrative area. e.g. state, city, town, etc + + + + + + + + + Details of Locality which is a named densely populated area (a place) such as town, village, suburb, etc. A locality composes of many individual addresses. Many localities exist in an administrative area or a sub adminisrative area. A locality can also have sub localities. For example, a municipality locality can have many villages associated with it which are sub localities. Example: Tamil Nadu State, Erode District, Bhavani Taluk, Paruvachi Village is a valid address in India. Tamil Nadu is the Administrative Area, Erode is the sub admin area, Bhavani is the locality, and Paruvachi is the sub locality + + + + + + Data associated with the locality. e.g. Full name of the locality or part of it, reference location to the locality + + + + + + + + semantics of data associated with name + + + + + name of locality represented as a code + + + + + type of code used to represent name as a code + + + + + + + + + + A locality that is smaller and is contained within the boundaries of its parent locality. Note that not all localities have sub locality. For example, many areas within a locality where each area is a sub locality + + + + + + Data associated with the sub locality. e.g. Full name of the locality or part of it, reference location to the locality + + + + + + + + semantics of data associated with name + + + + + name of locality represented as a code + + + + + type of code used to represent name as a code + + + + + + + + + + + Type of sub locality + + + + + + + + + + Type of locality. e.g. suburb, area, zone, village, etc + + + + + + + + + Details of the Access route along which buildings/lot/land are located, such as street, road, channel, crescent, avenue, etc. This also includes canals/banks on which houses/boat houses are located where people live + + + + + + + + Another thoroughfare that is required to uniquely identify the location, such as an access route, intersection, corner, adjacent, boundary, etc + + + + + + + + + + + + + + + Details of the Premises (could be building(s), site, loaction, property, premise, place) which is a landmark place which has a main address such as large mail user (e.g. Airport, Hospital, University) or could be a building (e.g. apartment, house) or a building or complex of buildings (e.g. an apartment complex or shopping centre) or even a vacant land (e.g. LOT). A premises can have many sub-addresses such as apartments in a building having its own addresses or buildings within an airport having its own addresses including its own thoroughfares + + + + + + + + Examples of sub-premises are apartments and suites in buildings, shops in malls, etc. or sub-addresses in a land mark place such as airports, military bases, hospitals, etc. Some countries have blocks within blocks + + + + + + + + Type of code used for sub premises type attribute + + + + + + + + + + + Type of code use for Premises Type attribute + + + + + + + + + A container for a single free text or structured postcode. Note that not all countries have post codes + + + + + + The postcode is formatted according to country-specific rules. Example: SW3 0A8-1A, 600074, 2067. This element can also be used to define the semantics of what each code in the post code means + + + + + + + + + + A container for postal-specific delivery identifier for remote communities. Note that not all countries have RuralDelivery + + + + + + Free text or structured description of rural delivery route. e.g. RD 6, + + + + + + Type of rural delivery. For some addresses, delivery to rural areas happens via water, air or road + + + + + + + + + Final mail delivery point where the mail is dropped off for recipients to pick them up directly. E.g. POBox, Private Bag, pigeon hole, free mail numbers, etc. + + + + + + Free text or structured description of a postal delivery point. + + + + + + + + + + + A delivery point/installation where all mails are delivered and the post man/delivery service picks up the mails and delivers it to the recipients through a delivery mode. Examples are a rural post office where post is delivered, a post office containing post office boxes/personal mail boxes. Note that not all countries have PostOffice. Can be used to represent overseas military addresses also along with PostalDeliveryPoint element + + + + + + Name or number of the post office in free text or structured form. + + + + + + Indicates the type of postal delivery office from where the mail will be distributed to the final delivery point by a delivery mode. Example: Post Office, Mail Collection Centre, Letter Carrier Depot, Station, etc. + + + + + + + + + GeoRSS GML from Open Geospatial Consortium (www.opengeospatial.net) is a formal GML Application Profile, and supports a greater range of features than Simple, notably coordinate reference systems other than WGS84 latitude/longitude. It is designed for use with Atom 1.0, RSS 2.0 and RSS 1.0, although it can be used just as easily in non-RSS XML encodings. + + + + + + Could be GeoRSS Simple or GeoRSS GML versions. Refer to http://georss.org/ and http://georss.org/gml for further documentation + + + + + + + + + Simple Geo-coordinates of the address/location + + + + + + Latitude details + + + + + Measure of the latitude in degrees + + + + + Measure of the latitude in minutes + + + + + Measure of the latitude in seconds + + + + + The direction of latitude measurement offset from the equator + + + + + + + + Longitude details + + + + + Measure of the longitude in degrees + + + + + Measure of the longitude in minutes + + + + + Measure of the longitude in seconds + + + + + The direction of longitude measurement offset from the equator + + + + + + + + + The collection of the coordinate numeric values for latitude amd longtitude depends on the agreed position of the meridian. Declaration of the meridian is necessary as it cannot be assumed in the data + + + + + Type of code used. e.g. EPSG Code + + + + + The collection of the coordinate numeric values depends on the agreed datum within which the measurement was taken. Declaration of the datum is necessary as it cannot be assumed in the data + + + + + Type of code used. e.g. EPSG Code, WGS-84 + + + + + Coordinates have limited utility and application depending on the projection required for visualisation in a map. Declaration of projection is necessary as it cannot be assumed in data + + + + + Type of code used. e.g. EPSG Code + + + + + + + + + + Defines the type of address. An address type can be" Primary Address, Secondary Address, Rural Address, Military Address, etc. + + + + + A unique address identifier such as postal delivery idetifier assigned to the address by local postal authority, e.g. DPID in Australia. + + + + + Type of address ID used. e.g. DPID, etc + + + + + A globally unique identifier assigned to the address + + + + + The purpose the address is used for. E.g. Postal, residential, business, exchange, update, create, delete, etc + + + + + Mode of delivery of address. For example: rural route, normal delivery, post office box, etc. + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + A primary key to reference Address. + + + + + A foreign key to reference attribute Key of Address. + + + + + + + + + + + + Complex type that defines the name of the country and is reused in other CIQ specs + + + + + Data associated with the name of the country in whatever form available, e.g. full, abbreviation, common use, code of the country, etc. + + + + + + + + Semantics of data associated with name. + + + + + Name of the country represented as a code + + + + + Type of code used to represent name of country, e.g. iso-3166 + + + + + + + + + + + + + Complex type for internal reuse + + + + + + Indicates which part of number or identifier this element contains. Some "numbers" are as simple as 42 and some "numbers" are more like complex aplhanumberic identifiers as Postcodes in UK or Canada, e.g. M2H 2S5. It may be necessary to separate the "number" into sub-elements and indicate what type of information each of them contains. + + + + + + + + + + Complex type for internal reuse + + + + + Data associated with the name of the Premises. e.g. Full name of premises or part of the name. E.g. Westfield shopping center, reference data to support the premises location, street in the premises + + + + + + + + Describes the type / part of name this element contains. + + + + + + + + + + Data associated with the number of the premises. E.g.House 15, number range, number suffix + + + + + + + + Complex type for internal reuse + + + + + Data associated with the thoroughfare details. e.g. Full thoroughfare name or part of it, type of thoroughfare, old name, new name, reference data in support of the thoroughfare + + + + + + + + Describes the type / part of name this element contains. + + + + + + + + + + Data associated with the number of the thoroughfare. E.g. 39 in 39 Baker Street, street range, street suffix + + + + + + Type of thoroughfare. eg. primary road, secondary road, road branch (e.g. Lane 14), road sub branch (e.g. Alley 21), adjourning street, cross street, closest street, etc + + + + + Type of code use for thoroughfare + + + + + + diff --git a/stix_validator/schema/external/oasis_ciq_3.0/xNAL-types.xsd b/stix_validator/schema/external/oasis_ciq_3.0/xNAL-types.xsd new file mode 100755 index 0000000..d66079f --- /dev/null +++ b/stix_validator/schema/external/oasis_ciq_3.0/xNAL-types.xsd @@ -0,0 +1,36 @@ + + + + + Specification Name: OASIS CIQ TC - extensible Name and Address Language Types (xNAL-types) + Description: Defines the W3C schema that provides enumeration lists to support xNAL v3.0 + (Using XML Schema based standard code list/enumeration mechanism - OPTION 1 AND DEFAULT) + Produced by: OASIS Customer Information Quality Technical Committee + URL: http://www.oasis-open.org/committees/ciq + Version: 3.0 + Status: Committee Specification CS02 + Copyright: 2007-09, OASIS, http://www.oasis-open.org + Last Modified: 20 September 2008 + Last Modified by: Ram Kumar, Chair, OASIS CIQ TC + + NOTE: This is the schema that users can customise the enumeration lists to meet their + exchange requirements. The enumeration values provided are ONLY SAMPLES and + is not complete. It is upto the application to decide what the values should be. To achieve + interoperability between applications using this specification, it is recommended that an + SLA/agreement is in place as to what the enumeration values will be used in this file + + Please note: These schemas have been modified by the STIX team to support remote validation. The only change made is to the schemaLocation attribute(s). + + + + A list of possible values for dependency name type + + + + + + A list of all types of Record IDs + + + + diff --git a/stix_validator/schema/external/oasis_ciq_3.0/xNAL.xsd b/stix_validator/schema/external/oasis_ciq_3.0/xNAL.xsd new file mode 100755 index 0000000..c09c6bc --- /dev/null +++ b/stix_validator/schema/external/oasis_ciq_3.0/xNAL.xsd @@ -0,0 +1,126 @@ + + + + + Specification Name: OASIS CIQ TC - extensible Name and Address Language (xNAL) + Description: Defines the W3C schema for representing name and address together + (Using XML Schema based standard code list/enumeration mechanism - OPTION 1 AND DEFAULT) + Produced by: OASIS Customer Information Quality Technical Committee + URL: http://www.oasis-open.org/committees/ciq + Version: 3.0 + Status: Committee Specification CS02 + Copyright: 2007-09, OASIS, http://www.oasis-open.org + Last Modified: 20 September 2008 + Last Modified by: Ram Kumar, Chair, OASIS CIQ TC + + NOTE: Do not modify this schema as it will break specifications compatibility + + Please note: These schemas have been modified by the STIX team to support remote validation. The only change made is to the schemaLocation attribute(s). + + + + + + + + This is a generic contianer to combine name and address. Any cardinality of names and addresses is permitted. + + + + + + + + + A unique identifier of a record + + + + + Type of Record ID + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + Primary key for referencing record + + + + + Foreign key to reference record + + + + + + + + + + This is a specialised container to combine name and address for postal purposes, e.g. a label on an envelope that has two parts, an addressee and the address. + + + + + + Addressee is the party that is the recipient of the postal mail delivery. + + + + + + When the name of the recipient is not known or the designation is still required to appear on the label. +E.g. Attention CEO, General Manager, the household owner, etc. + + + + + + + + + + + + + The main name has a relationship with a dependant name. +The dependant name should be put under this element and the relationship described. +E.g. Eastbourne Goats Trust in care of Wellingon Lawers Ltd., Ram Kumar, C/O Sakthisoft, etc + + + + + + + This attribute describes the nature/type of relationship between the main name and the dependency. E.g. 'C/O', 'in care of' or 'a son of'. + + + + + + + + + + + + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + + + + diff --git a/stix_validator/schema/external/oasis_ciq_3.0/xNL-types.xsd b/stix_validator/schema/external/oasis_ciq_3.0/xNL-types.xsd new file mode 100755 index 0000000..6210448 --- /dev/null +++ b/stix_validator/schema/external/oasis_ciq_3.0/xNL-types.xsd @@ -0,0 +1,222 @@ + + + + + Specification Name: OASIS CIQ TC - extensible Name Language Types (xNL-types) + Description: Defines the W3C schema that provides enumeration lists to support xNL v3.0 + (Using XML Schema based standard code list/enumeration mechanism - OPTION 1 AND DEFAULT) + Produced by: OASIS Customer Information Quality Technical Committee + URL: http://www.oasis-open.org/committees/ciq + Version: 3.0 + Status: Committee Specification CS02 + Copyright: 2007-09, OASIS, http://www.oasis-open.org + Last Modified: 20 September 2008 + Last Modified by: Ram Kumar, Chair, OASIS CIQ TC + + NOTE: This is the schema that users can customise the enumeration lists to meet their + exchange requirements. The enumeration values provided are ONLY SAMPLES and + is not complete. It is upto the application to decide what the values should be. To achieve + interoperability between applications using this specification, it is recommended that an + SLA/agreement is in place as to what the enumeration values will be used in this file + + Please note: These schemas have been modified by the STIX team to support remote validation. The only change made is to the schemaLocation attribute(s). + + + + A list of possible values for joint name connector + + + + + + A list of possible values for types of name lines + + + + + + A list of all types of Party Name IDs + + + + + + A list of usage types of party name + + + + + + A list of person name element types, e.g. First Name, Last Name, Title, etc. + + + + + His Excellency, Honorable, etc. + + + + + A title signifies some sort of status, such as Mr, Miss, Ms (marriage status), or education such as Professor, PhD, Dr, etc. + + + + + The most important name element by which this particular individual is identified in the group. E.g. John, Sam, Brian for Anglo-Saxon cultures. + + + + + Name elements related to additional identification of the individual, such as names are parents or places. + + + + + Name element that identifies the group the individual belongs to and is identified by, such as Last Name, Surname, Family Name, etc. + + + + + Any other additional names that are not directly used to identify or call the individual, such as names of ancestors, saints, etc. + + + + + A simple nick name that is commonly used as part of the name. E.g. a fancy kick-boxer can be commonly known as Bill "Storm" Bababoons, where "Storm" is obviously an alias. + + + + + Junior, Senior, The Second, IV, etc. + + + + + + + + A list of usage types of person name + + + + + + A list of all types of person name IDs + + + + + + A list of all types of organisation name IDs + + + + + + A list of organisation name element types, e.g. Name, propriety type, liability type, etc. + + + + + "Sakthisoft" in "Sakthisoft Pty. Ltd". "Pty.Ltd" is the legal entity for the organisation name "Sakthisoft" + + + + + "Pty. Ltd" in Sakthisoft Pty.Ltd, where "Sakthisoft" is the name of the organisation. + +""Inc" in ABC Inc, where "ABC" is organisation name + + + + + Full Name of the organisation. e.g. Sakthisoft Pty. Ltd + + + + + + + A list of usage types for organisation name + + + + + + A list of common types for person names + + + + + + + + Name of an individual before marriage. + + + + + Former name of the person + + + + + Name that is commonly used by others, e.g. a simplified form of the official name. + + + + + A name given to an individual at birth, but later changed (common in some cultures) + + + + + Indicates that the party prefers to be called by this name + + + + + An official name of the person, e.g. as in the passport. incorporation certificate, etc. + + + + + + + + + + A list of common types for organisation names + + + + + + Former name of the organisation + + + + + + + + + unknown + + + + + + + A list of common types for subdivisions + + + + + + + + + + + diff --git a/stix_validator/schema/external/oasis_ciq_3.0/xNL.xsd b/stix_validator/schema/external/oasis_ciq_3.0/xNL.xsd new file mode 100755 index 0000000..e5b44c0 --- /dev/null +++ b/stix_validator/schema/external/oasis_ciq_3.0/xNL.xsd @@ -0,0 +1,284 @@ + + + + + Specification Name: OASIS CIQ TC - extensible Name Language (xNL) + Description: Defines the W3C schema for representing party names (Person or Organisation) + (Using XML Schema based standard code list/enumeration mechanism - OPTION 1 AND DEFAULT) + Produced by: OASIS Customer Information Quality Technical Committee + URL: http://www.oasis-open.org/committees/ciq + Version: 3.0 + Status: Committee Specification CS02 + Copyright: 2007-09, OASIS, http://www.oasis-open.org + Last Modified: 20 September 2008 + Last Modified by: Ram Kumar, Chair, OASIS CIQ TC + + NOTE: Do not modify this schema as it will break specifications compatibility + + Please note: These schemas have been modified by the STIX team to support remote validation. The only change made is to the schemaLocation attribute(s). + + + + + + + Reference to another Person Name or Organisation Name with primary and foreign key reinforcement. + + + + A primary key to reference Party Name. + + + + + A foreign key to reference attribute Key of Party Name. + + + + + + Reusable complex type for a party. A party is a person or an organisation + + + + + + Container for person name details. Same person with many types (e.g. alias, pet name, nick name) of names can be used by this container. + + + + + + + + + + A container for organisation name details. Same organisaion with many types of names can be used by this container + + + + + + + + + + + A unique identifier of a party + + + + + Type of Party Name ID + + + + + Globally unique identifier + + + + + Tye of use of this data. e.g. data exchange, contact, update, create + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + The connector used to join more than one person name. Example: Mr Hunt AND Mrs Clark, where AND is the JointNameConnector. The flow is from the preceding to the following. If there is more than 2 names then all names are connected using this connector in the natural order. + + + + + + + + + + + + + + Reusable complex type + + + + + Name or part of a name. + + + + + + + Clarifies the meaning of the element.Could be first name, middle name, etc. that is defined in the List list. Omit this attribute if the type of the name element is not known. + + + + + + + + + + + + Enumerated list of type of name. example: Alias, Nick Name, former name, known as, etc + + + + + A unique identifier of a person + + + + + Type of identifier + + + + + Globally unique identifier + + + + + Usage of a person name. How is it used and for what purpose. Allows user which name in a set of names to select for a given purpose. +e.g. used for legal purposes + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + + + + + + + + + Reusable complex type + + + + + Name of the organisation. E.g. ACME Inc. + + + + + + + Clarifies the meaning of the element. Example: name, type . Omit this attribute if the type of the name element is not known. + + + + + + + + + + + Name of a subdivision of an organisation (e.g. department) + + + + + + + Type of sub division. e.g. department, warehouse, branch + + + + + + + + + + + + Enumerated list of common types of aliases or name types. + + + + + A unique identifier of an organisation + + + + + Type of identifier + + + + + Globally unique identifer + + + + + Usage of organisation name. How is it used and for what purpose. Allows user which name in a set of names to select for a given purpose. +e.g. used for legal purposes + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + + + + + + + + + Define name as a free format text. Use this when the type of the entity (person or organisation) is unknown, or is not broken down into individual elements (e.g. unstructured, unparsed) or is beyond the provided types. The name represented may be formatted in the right order or may not be as it is not parsed/broken into atomic fields + + + + + + + Type define what this free format name line could mean. For example, the Type could be "Unknown" + + + + + + + + + + + + Container for defining a name of a Person, an Organisation or combination of the above as a joint name. + + + + + Person Name + + + + + Organisation Name + + + diff --git a/stix_validator/schema/external/oasis_ciq_3.0/xPIL-types.xsd b/stix_validator/schema/external/oasis_ciq_3.0/xPIL-types.xsd new file mode 100755 index 0000000..6a481ab --- /dev/null +++ b/stix_validator/schema/external/oasis_ciq_3.0/xPIL-types.xsd @@ -0,0 +1,854 @@ + + + + + Specification Name: OASIS CIQ TC - extensible Party Information Language Types (xPIL-types) + Description: Defines the W3C schema that provides enumeration lists to support + xPIL. + (Using XML Schema based standard code list/enumeration mechanism - OPTION 1 AND DEFAULT) + Produced by: OASIS Customer Information Quality Technical Committee + URL: http://www.oasis-open.org/committees/ciq + Version: 3.0 + Status: Committee Specification CS02 + Copyright: 2007-09, OASIS, http://www.oasis-open.org + Last Modified: 20 September 2008 + Last Modified by: Ram Kumar, Chair, OASIS CIQ TC + + NOTE: This is the schema that users can customise the enumeration lists to meet their + exchange requirements. The enumeration values provided are ONLY SAMPLES and + is not complete. It is upto the application to decide what the values should be. To achieve + interoperability between applications using this specification, it is recommended that an + SLA/agreement is in place as to what the enumeration values will be used in this file + + Please note: These schemas have been modified by the STIX team to support remote validation. The only change made is to the schemaLocation attribute(s). + + + + List of information types used for account details + + + + + The unique name, number or mixed account identifier, e.g. bank account number + + + + + The organisation that assigns and manages the account, e.g. a bank, power supplier, etc. + + + + + Commonly recognised names, such as IRD number (for NZ), SSN (for US), ABN (for AU), etc. + + + + + + The country that issued the account + + + + + + + List of types of account ownerships + + + + + + List of types of accounts + + + + + + List of types of blood groups + + + + + + + + + + + + + + + List of body parts for marks + + + + + + List of locations on the body parts where the marks are found + + + + + + List of information types used for birth information + + + + + Commonly used in some oriental cultures + + + + + A free text descriprion of the birth place, e.g. country name, region, etc. + + + + + Specific to some cultures + + + + + + + List of communication media types used for contact purposes + + + + + + + + + + + + List of information types used for phone number details + + + + + Code to dial to a country. E.g. 1 for US, 44 for UK + + + + + Code to dial an area within a country. For example: "02" for Sydney, "03" for Melbourne + + + + + Local number as would be used by others within the same dialing area. + + + + + An extension to the number that is usually handled by some PABX + + + + + E.g. special access code + + + + + Any text that is not part of the phone number, but has some informational content, e.g. Ext. + + + + + Area code with local number if one line. May include national access numbers. + + + + + Full international number in one line. May include international access numbers. + + + + + + + List of types of uses of contact number + + + + + + List of causes of disability + + + + + + List of information types used for document details + + + + + Usually the number of the document, which can be alphanumeric + + + + + Name of the document.e.g. VISA, MASTERCARD for credit cards + + + + + A privilege the holder of the document was grunted. E.g. security access level + + + + + A restriction imposed on the holder of the document. E.g. learners license + + + + + A name of a larger group that recognises this document or supports it. + + + + + Verirfication/security code as in credit card + + + + + Category of the document such as Donor Type in License, +Gold Card, Silver Card, Platinum Card, etc + + + + + Place of issue of the document. e.g. Sydney, Australia + + + + + Access/Security code of the document + + + + + Use this if the enumeration list for type of document is not used. + + + + + + + List of types of documents + + + + + + + + + + + + + + + + List of electronic address identifiers + + + + + + + + + + + + + + + + + + + List of types of use of electronic address identifiers + + + + + + List of type of events + + + + + + List of person's physical features + + + + + + + + + + + + + + + List of types for free text lines for defining party characteristics as free format text + + + + + + List of type of gender + + + + + + List of type/category of habit + + + + + + List of type/category of hobby + + + + + + List if industry code + + + + + + List of industry type + + + + + + Lit of preference to use the language e.g. speak, read, write + + + + + + List of types of skills on languages + + + + + + + + + + + + + + Type of language e.g. by birth, by education + + + + + + List of types of marital status + + + + + + List of information types used for describing a membership + + + + + Membership identifier, e.g. membership number or some other type of ID + + + + + A privilege that the member can enjoy as part of the membership. E.g. access to free events. + + + + + A restriction that the membership imposes on the member, e.g. do not smoke. + + + + + Larger group or alliance name the membership provides access to. + + + + + Category of the membership such as Gold, Silver, Platinum, etc + + + + + Use this if the enumeration list for type of memberhsip is not used. + + + + + The country that issues the membership + + + + + Role in membership for a person , e.g. secretary, President, treasurer + + + + + + + List of types of memberships + + + + + + List of types of obtaining nationality + + + + + + List of name types for commonly used Number type + + + + + Indicates that the element contains the lower value of a range, e.g. 25 in 25-37 + + + + + Indicates that the value is a range, e.g. 25-37 + + + + + Indicates that the element contains the top value of a range, e.g. 25 in 25-37 + + + + + Indicates that the element contains some value that is important, but not exactly the number itself. E.g. A250, where A is the prefix to the number 250 + + + + + Indocates that the element contains some value that is important, but not exactly the number itself. E.g. 'bis' in '45 bis' + + + + + Indicates that the value is number, e.g. 2020 in ID 2020. The actual value can be alpha-numeric. + + + + + Indicates that the value is a separator that is expected to be preserved. Examples are / - #, etc. + + + + + Indicates that the value is an extension number of some identifier, e.g. 01 in ID 2330-01. 01 could be mean a specific semantics + + + + + + + List of information types used for describing an occupation + + + + + The actual role the person carries out. + + + + + + Name, role or position who the person reports to. + + + + + E.g. full-time, part-time, temporary, contract, etc. + + + + + Commonly used identifier for accounting purposes. + + + + + A rank in some ranking system, e.g. private, major, superintendant, Justice, etc.This is different from role + + + + + + + List of category the oranisation belongs to + + + + + + + + + + + + + + + + List of organisation nature of business + + + + + + List of type of organisation + + + + + + List of relationship types with an organisation + + + + + + Type of use of organisation details data + + + + + + List of types of party identifiers + + + + + + List of information types used for describing party identifiers + + + + + + + + + List of identifier types + + + + + + + + + + + Organisation or Person + + + + + + List of type of use of party data + + + + + + List of category the person belongs to + + + + + + + + + + + List of type of use of person details data + + + + + + List of ethnicity of person + + + + + + List of favourites of the person + + + + + + List of type of physical info for free text + + + + + + List of physical status of a person + + + + + + Type of relationship with a person + + + + + + Type of preferences of a person + + + + + + List of information types used for describing a qualification + + + + + Free text name of the qualification + + + + + Name of the major subject of the qualification + + + + + Name of a minor subject of the qualification + + + + + Grade (average?, percentage? ) achieved with the qualification. + + + + + Free text description of the duration of the course, e.g. 4 years, 1 month, etc. + + + + + Free text description of the date when the qualification was completed to the best known precision. + + + + + Award, or distinction that was awarded to the graduate, e.g. honors. + + + + + Restrictions imposed on the graduate, e.g. not valid before completion of 2 year practical work under supervision. + + + + + Details of any professional registration if required for practicing, e.g. for pharmacists, electricians, medical professionals. + + + + + Full time, part time, evening classes, extramural, etc. + + + + + + + List of religions of person + + + + + + List of residency statusof person + + + + + + Type of currency codes for revienue + + + + + + Type of sources of revenue + + + + + + Type of revenue + + + + + + List of type of units for measurement + + + + + + List of information types used for describing a vehicle + + + + + Free text make description, e.g. Toyota, Ford + + + + + Free text model description, e.g. Pajero, Falcon, etc. May include make as in Ford Falcon or Mitsubishi Pajero. If the make information is included then do not put the make as a separate element qualified with Make. + + + + + Free text data which can be a full date or a year. + + + + + Free text engine number + + + + + Free text chassis number + + + + + Free text body number + + + + + Free text license plate number + + + + + Number plate types are different. e.g. standard, premier, diplomat, etc + + + + + + Type of body. e.g. Sedan, Ute, Station wagon, 2 door, etc + + + + + Use this if the enumeration list for type of vehicle is not used. + + + + + + + List of types of vehicles + + + + + + List of information types used for describing a visa + + + + + Type of visa. e.g. Tourist, Visitor, Student + + + + + + Some visas are known by its code number. e.g. B1, E3, H-1, Class X1 + + + + + Name of the country for which the visa is issued to. + + + + + Free text description of the issuing place, e.g. country name and office name or country name and the city. For example US Embassy, Prague, +Australia, Sydney + + + + + Free text description of the length of maximum stay. E.g. 1 week, 2 months, etc. + + + + + Any restrictions imposed on the visa holder, e.g. not for employment, cannot work for more than 20 hours + + + + + Any privileges granted to the visa holder, e.g. departure fee waived, etc. + + + + + Any special conditions imposed on the visa holder. e.g. Not allowed to work for more than 10 hours a week + + + + + Single Entry, Multiple Entry, Double Entry, etc + + + + + diff --git a/stix_validator/schema/external/oasis_ciq_3.0/xPIL.xsd b/stix_validator/schema/external/oasis_ciq_3.0/xPIL.xsd new file mode 100755 index 0000000..3befc5d --- /dev/null +++ b/stix_validator/schema/external/oasis_ciq_3.0/xPIL.xsd @@ -0,0 +1,1621 @@ + + + + + Specification Name: OASIS CIQ TC - extensible Party Information Language (xPIL) + Description: Defines the W3C schema for representing party information (unique identifiers) + including party name and address + (Using XML Schema based standard code list/enumeration mechanism - OPTION 1 AND DEFAULT) + Produced by: OASIS Customer Information Quality Technical Committee + URL: http://www.oasis-open.org/committees/ciq + Version: 3.0 + Status: Committee Specification CS02 + Copyright: 2007-09, OASIS, http://www.oasis-open.org + Last Modified: 20 September 2008 + Last Modified by: Ram Kumar, Chair, OASIS CIQ TC + + NOTE: Do not modify this schema as it will break specifications compatibility + + Please note: These schemas have been modified by the STIX team to support remote validation. The only change made is to the schemaLocation attribute(s). + + + + + + + + + + A container for defining the unique characteristics of a party, which can be a person or organisation + + + + + A container for defining the unique characteristics of a person only + + + + + + + + + + A container for defining the unique characteristics of an organisation only + + + + + + A container for defining the unique characteristics of a party, which can be a person or organisation + + + + + + + + A container to define the accounts details of the party such as utility account, financil accounts + + + + + + A container for identification document and cards of the party that are unique to the party. e.g. license, identification card, credit card, etc + + + + + + + + A container for memberships of party with other organisations (e.g. industry groups) or social networks (clubs, association, etc) + + + + + Relationships with other parties (persons or organisations, and the nature of relationship). Examples: +- For person: Contacts, blood relatives, friends, referees, customers, etc +- for Organisation: Subsidiary, Parent company, Branches, Divisions, Partners, etc + + + + + Container for income / revenue information of the party (salary/organisation revenue) + + + + + + + Container for other organisation specific details that are not covered in this schema that are common to a party + + + + + Container for other person specific details that are not covered in this schema elements that are common to a party + + + + + + + + + + + + + + + + + + Type of Party. e.g. Person or an organisation. An organisation could be university, college, club, association, company, etc + + + + + A unique identifier for party + + + + + Type of PartyID + + + + + A globally unique identifier assigned to party + + + + + Type of use of party date. e.g. exchange, update, create + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + A primary key to reference Party. + + + + + A foreign key to reference attribute Key of Party. + + + + + + + + + + + + A container for defining the unique characteristics of a person only + + + + + + + + A container to define the accounts details of the party such as utility account, financil accounts + + + + + + A container for identification document and cards of the party that are unique to the party. e.g. license, identification card, credit card, etc + + + + + + + + A container for memberships of party with other organisations (e.g. industry groups) or social networks (clubs, association, etc) + + + + + Relationships with other parties (persons or organisations, and the nature of relationship). Examples: +- For person: Contacts, blood relatives, friends, referees, customers, etc +- for Organisation: Subsidiary, Parent company, Branches, Divisions, Partners, etc + + + + + Container for income / revenue information of the party (salary/organisation revenue) + + + + + + + Container for other person specific details that are not covered in this schema elements that are common to a party + + + + + + + + + + + + + + + + + + Type of use of this data. e.g. data exchange, contact, update, create + + + + + Status of the organisation details + + + + + + A primary key to reference Person Details. + + + + + A foreign key to reference attribute Key of Person Details. + + + + + + + + + A container for defining the unique characteristics of an organisation only + + + + + + + + A container to define the accounts details of the party such as utility account, financil accounts + + + + + + A container for identification document and cards of the party that are unique to the party. e.g. license, identification card, credit card, etc + + + + + + + + A container for memberships of party with other organisations (e.g. industry groups) or social networks (clubs, association, etc) + + + + + Relationships with other parties (persons or organisations, and the nature of relationship). Examples: +- For person: Contacts, blood relatives, friends, referees, customers, etc +- for Organisation: Subsidiary, Parent company, Branches, Divisions, Partners, etc + + + + + Container for income / revenue information of the party (salary/organisation revenue) + + + + + + + Container for other person specific details that are not covered in this schema elements that are common to a party + + + + + + Type of use of this data. e.g. data exchange, contact, update, create + + + + + Status of the organisation details + + + + + + A primary key to reference Organisation Details. + + + + + A foreign key to reference attribute Key of Organisation Details. + + + + + + + + + + + + + Free text description of the party as line 1, line 2, line n. + + + + + + + + + + Type (semantics or category) of free text data + + + + + + + + + + + + + + + A container to define the accounts details of the party + + + + + + Account details such as bank account, customer account with utilities + + + + + + Information about the account + + + + + + + If present, specifies the type of the information provided as text value of the element. + + + + + + + + + + Reference to a Party element that describes the organisation where the account is held. + + + + + + + + + + + Type of account. e.g. bank, customer, employee, etc + + + + + Joint, Individual, corporate, etc. + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + + + + + + + + + A container for all party addresses + + + + + + + + + + + + + + + + + A container for all kinds of telecommunication lines of party used for contact purposes. e.g. phone, fax, mobile, pager, etc. + + + + + + Universal telecommunication number structure + + + + + + Full contact number or part of it + + + + + + + If present, specifies type of the information provdied as text value of the element. + + + + + + + + + + + Free text explanation of the communication line type. e.g. telephone, land line, mobile, fax, pager, etc + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + Current Status of Contact Number + + + + + Nature of contact. Example: business, personal, free call, toll free, after hours, etc + + + + + Free text expression of contact hours. e.g. 9:00AM-5:00PM + + + + + + + + + + + + + + A container for identification document and cards of the party that are unique to the party. + + + + + + Passports, driver licenses, credit cards, certificates, etc. + + + + + + Full document desctiption or part of it. + + + + + + + If present, specifies the type of the information provided as text value of the element. + + + + + + + + + + Party Name as on the document if different from the main one. + + + + + Address details on the document + + + + + Reference to a Party element that describes the issuing organisation + + + + + + + + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + + + + + + + + + A container of different types of electronic addresses of party (e.g. email, chat, skype, etc) + + + + + + + + + + Type of electronic address identifier + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + Usage of electronic address identifier. e.g. business, personal + + + + + An electronic address identifier is usually stored (and probably exchanged) in conjunction with a label which is typically displayed and the URL/electronic identifier just links that label. + + + + + + + + + + + + + + + A container for a list of key events and dates of the events of the organisation and person + + + + + + Type of event for a person - e.g. marriage anniversary, death, daughter's birth, spouse birthday, etc. + +Type of event for organisation - date of formation/registration, date of closing down, date of liquidation, data of becoming public limited, etc + + + + + + + + Type of event. e.g. Anniversary. If "Anniversary" is type, then the text for Event could be "20th wedding anniversary" + + + + + + Record the exact date of the event here. For example, deceased date, company closed date, birthday date of spouse, etc + + + + + + + + + + + + + + + A container for a list of Identifiers to recognise the party such as customer identifer, social security number, tax number, etc + + + + + + Identifier to recognise the party such as customer identifer, social security number, National ID Card, tax number, buiness number, company number, company registration, etc + + + + + + Information about the identifer + + + + + + + + + + + + + Reference to a Party element that describes the issuing organisation + + + + + + Type of identifier. e.g. Tax Number + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + + + + + + + + + A container for memberships of party with other organisations (e.g. industry groups). + + + + + + Membership details + + + + + + Full description of membership or part of it + + + + + + + If present, specifies the type of the information provided as text value of the element. + + + + + + + + + + Reference to a Party element that describes the organisation where the memberships is held. + + + + + + + + + + + Type of membership. e.g + Type of membership. e.g IEEE, Rifles Club + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + + + + + + + + + A container for relationships with other parties (persons or organisations, and the nature of relationship). Can also use this to define an organisation hierarchy (parent and subsidiary organisations or branches/groups of organisations) + + + + + + Relationship with a party. e.g. Friend, Wife, referee. organisation, customer. etc + + + + + + + + + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + Type of party involved in the relationship, i.e. person or organisation + + + + + If tha party is person, then the type of relationship with the person such as Friend, Mother, wife, contact, referee + + + + + If tha party is organisation, then the type of relationship with the organisation such as employer, branch, head office, subsidiary, etc + + + + + + + + + + + + + + + Container for income / revenue information of the party + + + + + + Revenue/Income details + + + + + + + A three-letter currency code as per ISO 4217 + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + Begining of the period. Inclusive. + + + + + End of the period. Inclusive. + + + + + Defines the type of amount. Example: Total earning, profit, loss, turnover, etc. + + + + + Precision range where the value of the element is in the middle of the range. E.g. + + + + + + + + + + Where this revenue / income comes from, e.g. business stream, activity, etc. + + + + + Country from where the revenue is generated + + + + + If present and set to true indicates that the income / revenue is after tax. + + + + + + + + + + + + + + + A container for stocks invested information + + + + + + A Stock market listing details. The organisation could be listed on more than one country + + + + + The code name for the organisation as listed in the exchange. E.g. MOT for Motorola Inc + + + + + Free text name of the stock exchange or other market. E.g. NYSE or NZX + + + + + Name of the country where listed + + + + + date of investment + + + + + Quantity of shares.....1 million shares + + + + + date of listing + + + + + + + + + + + + + A container to define all the vehicles of the party + + + + + + Vehicle Details + + + + + + Full vehicle description of part of it + + + + + + + If present, specifies the type of the information provided as text value of the element. + + + + + + + + + + + Type of vehicle. Example: Motorbike, Truck, Car, Bicycle, 4WD, Jeep, etc + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + + + + + + + + + Container for organisation specific details that are not covered in this schema that is common to a party + + + + + Type of organisation. Free text description, e.g. Company, Trust, Bank, Society, Club, etc. + + + + + Type of category the organisation belongs to such as club, association, company, vendor, etc + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + Nature of the organisation. e.g. Public limited, Commercial, charity, non-commercial, etc. + + + + + Organisation Industry type such as IT, Manufacturing. + + + + + Industry code or classification + + + + + Type of code used for industry code + + + + + Free text description of organisation size in terms of number of employees + + + + + Operating hour start time of the organisation, e.g. 9:00am + + + + + Operating hour end time for the organisation. e.g. 5:00pm + + + + + + + + + + Container for person specific details that are not covered in this schema that is common to a party + + + + + Age of the person as integer + + + + + Type of category the person belongs such as customer, employee, friend, prospect, etc + + + + + Status of the person. e.g. living, deceased, retired. To log the date of the status such as death or retired, use "Events" element + + + + + Free text description of the current marital status, e.g. married, separated, divorced, separated, etc. + + + + + Ethnicity of the person, e.g. Asian, Chinese, African, etc. + + + + + Free text gender description. + + + + + Free text name of the religion + + + + + + + + + A container to define the Date of Birth details of a person + + + + + + Birth details of the person + + + + + + + If present, specifies the type of the information provided as text value of the element. + + + + + + + + + + Full location details (e.g. address) may be required to get the exact geo-cordinates for astrology purposes + + + + + + Birth data and time to the known precision. Usually, it is only the date that is known. Leave time as 00:00:00 if not known. + + + + + Specify the duration of the uncertainity period as a range where BirthDateTime is in the middle of the range. Uses xsd:duration as the data type. The time interval is in the format: PnYnMnDTnHnMnS +P: period (required), nY: number of years, nM: number of months, nD: number of days, T: start of a time section (required if hours, minutes or secords to be specified), nH: number of hours, nM: number of minutes, nS: number of seconds + +P5Y -> period of 5 years +P5Y2M10D -> 5 years, 2 months, 10 days, and 15 hours + + + + + + + + + A container for all citizenships and residencies (Permanent/temporary) of a person. + + + + + + Citizenship and residence information in a free-text form. + + + + + + + Type of residency. e.g. permenant resident, citizen, temporary resident + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + + + + + + + + + A container for a list of favourites of a person + + + + + + The favourites of the person + + + + + + + Type of favourite. e.g. author, food, book, sport, etc + +Cricket + Back to the Future + + + + + + + + + + + + + + + + A container for a list of habits of a person + + + + + + Personal habits. E.g. smoking, drinking, gambling, etc. + + + + + + + Category/type of habit. e.g. sports, food, reading, etc. If "Hot Drinks" is type, then text for Habit could be "Strong Black Coffee" + + + + + + + + + + + + + + + A container for a list of hobbies of a person + + + + + + A hobby of the person. E.g. craft, sport, recreational activity, etc. + + + + + + + Type/Category of Hobby. e.g. sports, travelling. If "Sport" is a type/category of hobby, then text for "Hobby" could be "Playing cricket" + + + + + + + + + + + + + + + A container for a list of languages spoken by a person. + + + + + + Name of the language spoken by the person + + + + + + + Mother tongue, by birth, etc + + + + + Indicates ability to speak: yes, no, poor, good, bad, average + + + + + Indicates ability to read: yes, no, poor, good, bad, average + + + + + Indicates ability to write: yes, no, poor, good, bad, average + + + + + Indicates ability to understand speech: yes, no, poor, good, bad, average + + + + + Indicates preferred language of communication (read and/or write and/or speak) + + + + + + + + + + + + + + + A container for a list of nationalities of a person + + + + + + Name of the country of nationality. Could be more than one nationality + + + + + + + Type of nationality - By birth, naturalization, citizen + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + + + + + + + + + A container for a list of occupations of a person + + + + + + Occupation details + + + + + + Full description of the occupation or part of it + + + + + + + If present, specifies the type of the information provided as text value of the element. + + + + + + + + + + Reference to a Party element that describes the employer. + + + + + + + + + + + Is the party self employed? A boolean value expected + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + + + + + + + + + A container for physical characteristics of a person + + + + + + Any other physical info not covered by elements here + + + + + + + Category or type of physical info + + + + + + + + + + + Description of a physical feature such as hair, height, eye color, etc. + + + + + + + If present, specifies the type of the information provided as text value of the element. + + + + + Defines the unit of measurement. Example: Inches, feet, cm, meters, days, months, years, kgs, pounds, etc. + + + + + + + + + + + Description of body marks, such as scars, tatoos, spots, etc. + + + + + + + Free text name/description of the body part where the mark is located + + + + + Free text description of where on the body part the mark is located. E.g. left hand side, front, back, etc + + + + + + + + + + + Description of person's disability. + + + + + + + Free text description of the cause of the disability, e.g. birth defect, accident, etc. + + + + + + + + + + + Description of the person's allergy. e.g. Allergic to Pencillin, milk products + + + + + + + + + + + + + Condition of health in terms of medical. e.g. Healthy, diabetic, hgh blood pressure, high cholestrol, etc + + + + + + + + + + + + + + + + + + + A container for a list of preferences of a person (e.g. seat position in flight, restuarants) + + + + + + Preferences of the person. e.g. seat in non smoking area, holiday with family than alone + + + + + + + Type of preference. e.g. seating position + + + + + + + + + + + + + + + A container for a list of qualifications of a person + + + + + + Educational qualification + + + + + + Full / partial name or description of person's qualification + + + + + + + If present, specifies the type of the information provided as text value of the element. + + + + + + + + + + Reference to a Party element that describes the institution. + + + + + + + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + + + + + + + + + A container to define the VISAs held by a person (e.g. visitor, temporary, permanent resident, work, etc) + + + + + + All information about Visa details. + + + + + + Visa category number depending upon the type of visa. Example: H-1 for employment visa as in the USA + + + + + + + If present, specifies the type of the information provided as text value of the element. + + + + + + + + + + + Status of the entity. e.g. Old, Current, Inactive, Active, etc + + + + + + + + + + + + + + diff --git a/stix_validator/schema/external/oasis_ciq_3.0/xlink-2003-12-31.xsd b/stix_validator/schema/external/oasis_ciq_3.0/xlink-2003-12-31.xsd new file mode 100755 index 0000000..dc6b018 --- /dev/null +++ b/stix_validator/schema/external/oasis_ciq_3.0/xlink-2003-12-31.xsd @@ -0,0 +1,90 @@ + + + + + + XLink attribute specification + + + + + + + Enumeration of values for the type attribute + + + + + + + + + + + + + + + + + A URI with a minimum length of 1 character. + + + + + + + + + + + + A URI with a minimum length of 1 character. + + + + + + + + + + + + + Enumeration of values for the show attribute + + + + + + + + + + + + + + + + Enumeration of values for the actuate attribute + + + + + + + + + + + + + + + diff --git a/stix_validator/schema/external/open_ioc_2010/ioc-TR.xsd b/stix_validator/schema/external/open_ioc_2010/ioc-TR.xsd new file mode 100755 index 0000000..eb2e2d1 --- /dev/null +++ b/stix_validator/schema/external/open_ioc_2010/ioc-TR.xsd @@ -0,0 +1,25 @@ + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/external/open_ioc_2010/ioc.xsd b/stix_validator/schema/external/open_ioc_2010/ioc.xsd new file mode 100755 index 0000000..c4223ca --- /dev/null +++ b/stix_validator/schema/external/open_ioc_2010/ioc.xsd @@ -0,0 +1,105 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/stix_validator/schema/external/oval_5.10/oval-common-schema.xsd b/stix_validator/schema/external/oval_5.10/oval-common-schema.xsd new file mode 100755 index 0000000..580d279 --- /dev/null +++ b/stix_validator/schema/external/oval_5.10/oval-common-schema.xsd @@ -0,0 +1,781 @@ + + + + The following is a description of the common types that are shared across the different schemas within Open Vulnerability and Assessment Language (OVAL). Each type is described in detail and should provide the information necessary to understand what each represents. This document is intended for developers and assumes some familiarity with XML. A high level description of the interaction between these type is not outlined here. + The OVAL Schema is maintained by The MITRE Corporation and developed by the public OVAL Community. For more information, including how to get involved in the project and how to submit change requests, please visit the OVAL website at http://oval.mitre.org. + + Core Common + 5.10.1 + 1/27/2012 1:22:32 PM + Copyright (c) 2002-2012, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the OVAL License located at http://oval.mitre.org/oval/about/termsofuse.html. See the OVAL License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the OVAL Schema, this license header must be included. + + + + + + + + + + The deprecated_info element is used in documenting deprecation information for items in the OVAL Language. It is declared globally as it can be found in any of the OVAL schemas and is used as part of the appinfo documentation and therefore it is not an element that can be declared locally and based off a global type.. + + + + + The element_mapping element is used in documenting which tests, objects, states, and system characteristic items are associated with each other. It provides a way to explicitly and programatically associate the test, object, state, and item definitions. + + + + + + + + The ElementMapType is used to document the association between OVAL test, object, state, and item entities. + + + + + The local name of an OVAL test. + + + + + The local name of an OVAL object. + + + + + The local name of an OVAL state. + + + + + The local name of an OVAL item. + + + + + + + Defines a reference to an OVAL entity using the schema namespace and element name. + + + + + + The target_namespace attributes indicates what XML namespace the element belongs to. If not present, the namespace is that of the document in which the ElementMapItemType instance element appears. + + + + + + + + The DeprecatedInfoType complex type defines a structure that will be used to flag schema-defined constructs as deprecated. It holds information related to the version of OVAL when the construct was deprecated along with a reason and comment. + + + + + The required version child element details the version of OVAL in which the construct became deprecated. + + + + + + + + + + The required reason child element is used to provide an explanation as to why an item was deprecated and to direct a reader to possible alternative structures within OVAL. + + + + + The optional comment child element is used to supply additional information regarding the element's deprecated status. + + + + + + + The GeneratorType complex type defines an element that is used to hold information about when a particular OVAL document was compiled, what version of the schema was used, what tool compiled the document, and what version of that tool was used. + Additional generator information is also allowed although it is not part of the official OVAL Schema. Individual organizations can place generator information that they feel are important and these will be skipped during the validation. All OVAL really cares about is that the stated generator information is there. + + + + + The optional product_name specifies the name of the application used to generate the file. Product names SHOULD be expressed as CPE Names according to the Common Platform Enumeration: Name Matching Specification Version 2.3. + + + + + The optional product_version specifies the version of the application used to generate the file. + + + + + The required schema_version specifies the version of the OVAL Schema that the document has been written in and that should be used for validation. + + + + + + + + + + + The required timestamp specifies when the particular OVAL document was compiled. The format for the timestamp is yyyy-mm-ddThh:mm:ss. Note that the timestamp element does not specify when a definition (or set of definitions) was created or modified but rather when the actual XML document that contains the definition was created. For example, the document might have pulled a bunch of existing OVAL Definitions together, each of the definitions having been created at some point in the past. The timestamp in this case would be when the combined document was created. + + + + + The Asset Identification specification (http://scap.nist.gov/specifications/ai/) provides a standardized way of reporting asset information across different organizations. + Asset Identification elements can hold data useful for identifying what tool, what version of that tool was used, and identify other assets used to compile an OVAL document, such as persons or organizations. + To support greater interoperability, an ai:assets element describing assets used to produce an OVAL document may appear at this point in an OVAL document. + + + + + + + The MessageType complex type defines the structure for which messages are relayed from the data collection engine. Each message is a text string that has an associated level attribute identifying the type of message being sent. These messages could be error messages, warning messages, debug messages, etc. How the messages are used by tools and whether or not they are displayed to the user is up to the specific implementation. Please refer to the description of the MessageLevelEnumeration for more information about each type of message. + + + + + + + + + + + + + The CheckEnumeration simple type defines acceptable check values, which are used to determine the final result of something based on the results of individual components. When used to define the relationship between objects and states, each check value defines how many of the matching objects (items except those with a status of does not exist) must satisfy the given state for the test to return true. When used to define the relationship between instances of a given entity, the different check values defines how many instances must be true for the entity to return true. When used to define the relationship between entities and multiple variable values, each check value defines how many variable values must be true for the entity to return true. + + Below are some tables that outline how each check attribute effects evaluation. The far left column identifies the check attribute in question. The middle column specifies the different combinations of individual results that the check attribute may bind together. (T=true, F=false, E=error, U=unknown, NE=not evaluated, NA=not applicable) For example, a 1+ under T means that one or more individual results are true, while a 0 under U means that zero individual results are unknown. The last column specifies what the final result would be according to each combination of individual results. Note that if the individual test is negated, then a true result is false and a false result is true, all other results stay as is. + + || num of individual results || + check attr is || || final result is + || T | F | E | U | NE | NA || +---------------||-----------------------------||------------------ + || 1+ | 0 | 0 | 0 | 0 | 0+ || True + || 0+ | 1+ | 0+ | 0+ | 0+ | 0+ || False + ALL || 0+ | 0 | 1+ | 0+ | 0+ | 0+ || Error + || 0+ | 0 | 0 | 1+ | 0+ | 0+ || Unknown + || 0+ | 0 | 0 | 0 | 1+ | 0+ || Not Evaluated + || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable +---------------||-----------------------------||------------------ + + + || num of individual results || + check attr is || || final result is + || T | F | E | U | NE | NA || +---------------||-----------------------------||------------------ + || 1+ | 0+ | 0+ | 0+ | 0+ | 0+ || True + || 0 | 1+ | 0 | 0 | 0 | 0+ || False + AT LEAST ONE || 0 | 0+ | 1+ | 0+ | 0+ | 0+ || Error + || 0 | 0+ | 0 | 1+ | 0+ | 0+ || Unknown + || 0 | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated + || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable +---------------||-----------------------------||------------------ + + + || num of individual results || + check attr is || || final result is + || T | F | E | U | NE | NA || +---------------||-----------------------------||------------------ + || 1 | 0+ | 0 | 0 | 0 | 0+ || True + || 2+ | 0+ | 0+ | 0+ | 0+ | 0+ || ** False ** + || 0 | 1+ | 0 | 0 | 0 | 0+ || ** False ** + ONLY ONE ||0,1 | 0+ | 1+ | 0+ | 0+ | 0+ || Error + ||0,1 | 0+ | 0 | 1+ | 0+ | 0+ || Unknown + ||0,1 | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated + || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable +---------------||-----------------------------||------------------ + + + || num of individual results || + check attr is || || final result is + || T | F | E | U | NE | NA || +---------------||-----------------------------||------------------ + || 0 | 1+ | 0 | 0 | 0 | 0+ || True + || 1+ | 0+ | 0+ | 0+ | 0+ | 0+ || False + NONE SATISFY || 0 | 0+ | 1+ | 0+ | 0+ | 0+ || Error + || 0 | 0+ | 0 | 1+ | 0+ | 0+ || Unknown + || 0 | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated + || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable +---------------||-----------------------------||------------------ + + + + + + + A value of 'all' means that a final result of true is given if all the individual results under consideration are true. + + + + + A value of 'at least one' means that a final result of true is given if at least one of the individual results under consideration is true. + + + + + A value of 'none exists' means that a test evaluates to true if no matching object exists that satisfy the data requirements. + + + 5.3 + Replaced by the 'none satisfy' value. In version 5.3 of the OVAL Language, the checking of existence and state were separated into two distinct checks CheckEnumeration (state) and ExistenceEnumeration (existence). Since CheckEnumeration is now used to specify how many objects should satisfy a given state for a test to return true, and no longer used for specifying how many objects must exist for a test to return true, a value of 'none exist' is no longer needed. See the 'none satisfy' value. + This value has been deprecated and will be removed in version 6.0 of the language. + + + + + DEPRECATED ATTRIBUTE VALUE IN: ATTRIBUTE VALUE: + + + + + + + + + A value of 'none satisfy' means that a final result of true is given if none the individual results under consideration are true. + + + + + A value of 'only one' means that a final result of true is given if one and only one of the individual results under consideration are true. + + + + + + + The ClassEnumeration simple type defines the different classes of definitions. Each class defines a certain intent regarding how an OVAL Definition is written and what that definition is describing. The specified class gives a hint about the definition so a user can know what the definition writer is trying to say. Note that the class does not make a statement about whether a true result is good or bad as this depends on the use of an OVAL Definition. These classes are also used to group definitions by the type of system state they are describing. For example, this allows users to find all the vulnerability (or patch, or inventory, etc) definitions. + + + + + A compliance definition describes the state of a machine as it complies with a specific policy. A definition of this class will evaluate to true when the system is found to be compliant with the stated policy. Another way of thinking about this is that a compliance definition is stating "the system is compliant if ...". + + + + + An inventory definition describes whether a specific piece of software is installed on the system. A definition of this class will evaluate to true when the specified software is found on the system. Another way of thinking about this is that an inventory definition is stating "the software is installed if ...". + + + + + The 'miscellaneous' class is used to identify definitions that do not fall into any of the other defined classes. + + + + + A patch definition details the machine state of whether a patch executable should be installed. A definition of this class will evaluate to true when the specified patch is missing from the system. Another way of thinking about this is that a patch definition is stating "the patch should be installed if ...". Note that word SHOULD is intended to mean more than just CAN the patch executable be installed. In other words, if a more recent patch is already installed then the specified patch might not need to be installed. + + + + + A vulnerability definition describes the conditions under which a machine is vulnerable. A definition of this class will evaluate to true when the system is found to be vulnerable with the stated issue. Another way of thinking about this is that a vulnerability definition is stating "the system is vulnerable if ...". + + + + + + + The SimpleDatatypeEnumeration simple type defines the legal datatypes that are used to describe the values of individual entities that can be represented in a XML string field. The value may have structure and a pattern, but it is represented as string content. + + + + + The binary datatype is used to represent hex-encoded data that is in raw (non-printable) form. This datatype conforms to the W3C Recommendation for binary data meaning that each binary octet is encoded as a character tuple, consisting of two hexadecimal digits {[0-9a-fA-F]} representing the octet code. Expected operations within OVAL for binary values are 'equals' and 'not equal'. + + + + + The boolean datatype represents standard boolean data, either true or false. This datatype conforms to the W3C Recommendation for boolean data meaning that the following literals are legal values: {true, false, 1, 0}. Expected operations within OVAL for boolean values are 'equals' and 'not equal'. + + + + + The evr_string datatype represents the epoch, version, and release fields as a single version string. It has the form "EPOCH:VERSION-RELEASE". Comparisons involving this datatype should follow the algorithm of librpm's rpmvercmp() function. Expected operations within OVAL for evr_string values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'. + + + + + The fileset_revision datatype represents the version string related to filesets in HP-UX. An example would be 'A.03.61.00'. For more information, see the HP-UX "Software Distributor Administration Guide" (http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01919399/c01919399.pdf). Expected operations within OVAL for fileset_version values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'. + + + + + The float datatype describes standard float data. This datatype conforms to the W3C Recommendation for float data meaning it is patterned after the IEEE single-precision 32-bit floating point type. The format consists of a decimal followed, optionally, by the character 'E' or 'e', followed by an integer exponent. The special values positive and negative infinity and not-a-number have are represented by INF, -INF and NaN, respectively. Expected operations within OVAL for float values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'. + + + + + The ios_version datatype describes Cisco IOS Train strings. These are in essence version strings for IOS. Please refer to Cisco's IOS Reference Guide for information on how to compare different Trains as they follow a very specific pattern. Expected operations within OVAL for ios_version values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'. + + + + + The int datatype describes standard integer data. This datatype conforms to the W3C Recommendation for integer data which follows the standard mathematical concept of the integer numbers. (no decimal point and infinite range) Expected operations within OVAL for int values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', 'less than or equal', 'bitwise and', and 'bitwise or'. + + + + + The ipv4_address datatype represents IPv4 addresses and IPv4 address prefixes (using CIDR notation). Legal values are represented in dotted-quad notation ('a.b.c.d' where 'a', 'b', 'c', and 'd' are integers from 0-255), optionally followed by a slash ('/') and either a prefix-length (an integer from 0-32) or a netmask represented in dotted-quad notation ('a.b.c.d' where 'a', 'b', 'c', and 'd' are integers from 0-255). Examples of legal values are '192.0.2.0', '192.0.2.0/32', and '192.0.2.0/255.255.255.255'. Additionally, leading zeros are permitted such that '192.0.2.0' is equal to '192.000.002.000'. Expected operations within OVAL for ipv4_address values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', 'less than or equal', 'subset of', and 'superset of'. + The 'subset of' operation is used to compare sets of IP addresses. When using this operation, an IP address prefix defines the set of IP addresses as specified by CIDR notation and a IP address defines the set of one IP address. The result will be 'true', if the actual set of IP addresses on the system is a subset of the set defined by the stated entity. This means that every IP address in the set of IP addresses on the system must be present in the set of IP addresses defined in the stated entity. Otherwise, the result will be 'false'. + The 'superset of' operation is used to compare sets of IP addresses. When using this operation, an IP address prefix defines the set of IP addresses as specified by CIDR notation and a IP address defines the set of one IP address. The result will be 'true', if the actual set of IP addresses on the system is a superset of the set defined by the stated entity. This means that every IP address in the set of IP addresses defined in the stated entity is present in the set of IP addresses on the system. Otherwise, the result will be 'false'. + + + + + The ipv6_address datatype represents IPv6 addresses and IPv6 address prefixes (using CIDR notation). This datatype conforms to the IETF specification RFC 4291 for textual representations of IPv6 addresses and IPv6 address prefixes (See Section 2.2 and 2.3). Expected operations within OVAL for ipv6_address values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', 'less than or equal', 'subset of', and 'superset of'. + The 'subset of' operation is used to compare sets of IP addresses. When using this operation, an IP address prefix defines the set of IP addresses as specified by CIDR notation and a IP address defines the set of one IP address. The result will be 'true', if the actual set of IP addresses on the system is a subset of the set defined by the stated entity. This means that every IP address in the set of IP addresses on the system must be present in the set of IP addresses defined in the stated entity. Otherwise, the result will be 'false'. + The 'superset of' operation is used to compare sets of IP addresses. When using this operation, an IP address prefix defines the set of IP addresses as specified by CIDR notation and a IP address defines the set of one IP address. The result will be 'true', if the actual set of IP addresses on the system is a superset of the set defined by the stated entity. This means that every IP address in the set of IP addresses defined in the stated entity is present in the set of IP addresses on the system. Otherwise, the result will be 'false'. + + + + + The string datatype describes standard string data. This datatype conforms to the W3C Recommendation for string data. Expected operations within OVAL for string values are 'equals', 'not equal', 'case insensitive equals', 'case insensitive not equal', 'pattern match'. + + + + + The version datatype represents a value that is a hierarchical list of non-negative integers separated by a single character delimiter. Note that any non-number character can be used as a delimiter and that different characters can be used within the same version string. So '#.#-#' is the same as '#.#.#' or '#c#c#' where '#' is any non-negative integer. Expected operations within OVAL for version values are 'equals', 'not equal', 'greater than', 'greater than or equal', 'less than', and 'less than or equal'. + For example '#.#.#' or '#-#-#-#' where the numbers to the left are more significant than the numbers to the right. When performing an 'equals' operation on a version datatype, you should first check the left most number for equality. If that fails, then the values are not equal. If it succeeds, then check the second left most number for equality. Continue checking the numbers from left to right until the last number has been checked. If, after testing all the previous numbers, the last number is equal then the two versions are equal. When performing other operations, such as 'less than', 'less than or equal', 'greater than, or 'greater than or equal', similar logic as above is used. Start with the left most number and move from left to right. For each number, check if it is less than the number you are testing against. If it is, then the version in question is less than the version you are testing against. If the number is equal, then move to check the next number to the right. For example, to test if 5.7.23 is less than or equal to 5.8.0 you first compare 5 to 5. They are equal so you move on to compare 7 to 8. 7 is less than 8 so the entire test succeeds and 5.7.23 is 'less than or equal' to 5.8.0. The difference between the 'less than' and 'less than or equal' operations is how the last number is handled. If the last number is reached, the check should use the given operation (either 'less than' and 'less than or equal') to test the number. For example, to test if 4.23.6 is greater than 4.23.6 you first compare 4 to 4. They are equal so you move on to compare 23 to 23. They are equal so you move on to compare 6 to 6. This is the last number in the version and since 6 is not greater than 6, the entire test fails and 4.23.6 is not greater than 4.23.6. + Version strings with a different number of components shall be padded with zeros to make them the same size. For example, if the version strings '1.2.3' and '6.7.8.9' are being compared, then the short one should be padded to become '1.2.3.0'. + + + + + + + The ComplexDatatypeEnumeration simple type defines the complex legal datatypes that are supported in OVAL. These datatype describe the values of individual entities where the entity has some complex structure beyond simple string like content. + + + + + The record datatype describes an entity with structured set of named fields and values as its content. The only allowed operation within OVAL for record values is 'equals'. Note that the record datatype is not currently allowed when using variables. + + + + + + + The DatatypeEnumeration simple type defines the legal datatypes that are used to describe the values of individual entities. A value should be interpreted according to the specified type. This is most important during comparisons. For example, is '21' less than '123'? will evaluate to true if the datatypes are 'int', but will evaluate to 'false' if the datatypes are 'string'. Another example is applying the 'equal' operation to '1.0.0.0' and '1.0'. With datatype 'string' they are not equal, with datatype 'version' they are. + + + + + + The ExistenceEnumeration simple type defines acceptable existence values, which are used to determine a result based on the existence of individual components. The main use for this is for a test regarding the existence of objects on the system. + + Below are some tables that outline how each ExistenceEnumeration value effects evaluation of a given test. Note that this is related to the existence of an object(s) and not the object(s) compliance with a state. The left column identifies the ExistenceEnumeration value in question. The middle column specifies the different combinations of individual item status values that have been found in the system characteristics file related to the given object. (EX=exists, DE=does not exist, ER=error, NC=not collected) For example, a 1+ under EX means that one or more individual item status attributes are set to exists, while a 0 under NC means that zero individual item status attributes are set to not collected. The last column specifies what the result of the existence piece would be according to each combination of individual item status values. + + || item status value count || + attr value || || existence piece is + || EX | DE | ER | NC || +---------------||---------------------------||------------------ + || 1+ | 0 | 0 | 0 || True + || 0 | 0 | 0 | 0 || False + || 0+ | 1+ | 0+ | 0+ || False + all_exist || 0+ | 0 | 1+ | 0+ || Error + || 0+ | 0 | 0 | 1+ || Unknown + || -- | -- | -- | -- || Not Evaluated + || -- | -- | -- | -- || Not Applicable +---------------||---------------------------||------------------ + + + || item status value count || + attr value || || existence piece is + || EX | DE | ER | NC || +---------------||---------------------------||------------------ + || 0+ | 0+ | 0 | 0+ || True + || 1+ | 0+ | 1+ | 0+ || True + || -- | -- | -- | -- || False + any_exist || 0 | 0+ | 1+ | 0+ || Error + || -- | -- | -- | -- || Unknown + || -- | -- | -- | -- || Not Evaluated + || -- | -- | -- | -- || Not Applicable +---------------||---------------------------||------------------ + + + || item status value count || + attr value || || existence piece is + || EX | DE | ER | NC || +---------------||---------------------------||------------------ + || 1+ | 0+ | 0+ | 0+ || True + || 0 | 1+ | 0 | 0 || False +at_least_one_exists || 0 | 0+ | 1+ | 0+ || Error + || 0 | 0+ | 0 | 1+ || Unknown + || -- | -- | -- | -- || Not Evaluated + || -- | -- | -- | -- || Not Applicable +---------------||---------------------------||------------------ + + + || item status value count || + attr value || || existence piece is + || EX | DE | ER | NC || +---------------||---------------------------||------------------ + || 0 | 0+ | 0 | 0 || True + || 1+ | 0+ | 0+ | 0+ || False + none_exist || 0 | 0+ | 1+ | 0+ || Error + || 0 | 0+ | 0 | 1+ || Unknown + || -- | -- | -- | -- || Not Evaluated + || -- | -- | -- | -- || Not Applicable +---------------||---------------------------||------------------ + + + || item status value count || + attr value || || existence piece is + || EX | DE | ER | NC || +---------------||---------------------------||------------------ + || 1 | 0+ | 0 | 0 || True + || 2+ | 0+ | 0+ | 0+ || False + || 0 | 0+ | 0 | 0 || False + only_one_exists || 0,1 | 0+ | 1+ | 0+ || Error + || 0,1 | 0+ | 0 | 1+ || Unknown + || -- | -- | -- | -- || Not Evaluated + || -- | -- | -- | -- || Not Applicable +---------------||---------------------------||------------------ + + + + + + + A value of 'all_exist' means that every object defined by the description exists on the system. + + + + + A value of 'any_exist' means that zero or more objects defined by the description exist on the system. + + + + + A value of 'at_least_one_exists' means that at least one object defined by the description exists on the system. + + + + + A value of 'none_exist' means that none of the objects defined by the description exist on the system. + + + + + A value of 'only_one_exists' means that only one object defined by the description exists on the system. + + + + + + + The FamilyEnumeration simple type is a listing of families that OVAL supports at this time. Since new family values can only be added with new version of the schema, the value of 'undefined' is to be used when the desired family is not available. Note that use of the undefined family value does not target all families, rather it means that some family other than one of the defined values is targeted. + + + + + The catos value describes the Cisco CatOS operating system. + + + + + The ios value describes the Cisco IOS operating system. + + + + + The macos value describes the Mac operating system. + + + + + The pixos value describes the Cisco PIX operating system. + + + + + The undefined value is to be used when the desired family is not available. + + + + + The unix value describes the UNIX operating system. + + + + + The vmware_infrastructure value describes VMWare Infrastructure. + + + + + The windows value describes the Microsoft Windows operating system. + + + + + + + The MessageLevelEnumeration simple type defines the different levels associated with a message. There is no specific criteria about which messages get assigned which level. This is completely arbitrary and up to the content producer to decide what is an error message and what is a debug message. + + + + + Debug messages should only be displayed by a tool when run in some sort of verbose mode. + + + + + Error messages should be recorded when there was an error that did not allow the collection of specific data. + + + + + A fatal message should be recorded when an error causes the failure of more than just a single piece of data. + + + + + Info messages are used to pass useful information about the data collection to a user. + + + + + A warning message reports something that might not correct but information was still collected. + + + + + + + The OperationEnumeration simple type defines acceptable operations. Each operation defines how to compare entities against their actual values. + + + + + The 'equals' operation returns true if the actual value on the system is equal to the stated entity. When the specified datatype is a string, this results in a case-sensitive comparison. + + + + + The 'not equal' operation returns true if the actual value on the system is not equal to the stated entity. When the specified datatype is a string, this results in a case-sensitive comparison. + + + + + The 'case insensitive equals' operation is meant for string data and returns true if the actual value on the system is equal (using a case insensitive comparison) to the stated entity. + + + + + The 'case insensitive not equal' operation is meant for string data and returns true if the actual value on the system is not equal (using a case insensitive comparison) to the stated entity. + + + + + The 'greater than' operation returns true if the actual value on the system is greater than the stated entity. + + + + + The 'less than' operation returns true if the actual value on the system is less than the stated entity. + + + + + The 'greater than or equal' operation returns true if the actual value on the system is greater than or equal to the stated entity. + + + + + The 'less than or equal' operation returns true if the actual value on the system is less than or equal to the stated entity. + + + + + The 'bitwise and' operation is used to determine if a specific bit is set. It returns true if performing a BITWISE AND with the binary representation of the stated entity against the binary representation of the actual value on the system results in a binary value that is equal to the binary representation of the stated entity. For example, assuming a datatype of 'int', if the actual integer value of the setting on your machine is 6 (same as 0110 in binary), then performing a 'bitwise and' with the stated integer 4 (0100) returns 4 (0100). Since the result is the same as the state mask, then the test returns true. If the actual value on your machine is 1 (0001), then the 'bitwise and' with the stated integer 4 (0100) returns 0 (0000). Since the result is not the same as the stated mask, then the test fails. + + + + + The 'bitwise or' operation is used to determine if a specific bit is not set. It returns true if performing a BITWISE OR with the binary representation of the stated entity against the binary representation of the actual value on the system results in a binary value that is equal to the binary representation of the stated entity. For example, assuming a datatype of 'int', if the actual integer value of the setting on your machine is 6 (same as 0110 in binary), then performing a 'bitwise or' with the stated integer 14 (1110) returns 14 (1110). Since the result is the same as the state mask, then the test returns true. If the actual value on your machine is 1 (0001), then the 'bitwise or' with the stated integer 14 (1110) returns 15 (1111). Since the result is not the same as the stated mask, then the test fails. + + + + + The 'pattern match' operation allows an item to be tested against a regular expression. When used by an entity in an OVAL Object, the regular expression represents the unique set of matching items on the system. OVAL supports a common subset of the regular expression character classes, operations, expressions and other lexical tokens defined within Perl 5's regular expression specification. For more information on the supported regular expression syntax in OVAL see: http://oval.mitre.org/language/about/re_support_5.6.html + + + + + The 'subset of' operation returns true if the actual set on the system is a subset of the set defined by the stated entity. + + + + + The 'superset of' operation returns true if the actual set on the system is a superset of the set defined by the stated entity. + + + + + + + The OperatorEnumeration simple type defines acceptable operators. Each operator defines how to evaluate multiple arguments. + + Below are some tables that outline how each operator effects evaluation. The far left column identifies the operator in question. The middle column specifies the different combinations of individual results that the operator may bind together. (T=true, F=false, E=error, U=unknown, NE=not evaluated, NA=not applicable) For example, a 1+ under T means that one or more individual results are true, while a 0 under U means that zero individual results are unknown. The last column specifies what the final result would be according to each combination of individual results. Note that if the individual test is negated, then a true result is false and a false result is true, all other results stay as is. + + || num of individual results || + operator is || || final result is + || T | F | E | U | NE | NA || +---------------||-----------------------------||------------------ + || 1+ | 0 | 0 | 0 | 0 | 0+ || True + || 0+ | 1+ | 0+ | 0+ | 0+ | 0+ || False + AND || 0+ | 0 | 1+ | 0+ | 0+ | 0+ || Error + || 0+ | 0 | 0 | 1+ | 0+ | 0+ || Unknown + || 0+ | 0 | 0 | 0 | 1+ | 0+ || Not Evaluated + || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable +---------------||-----------------------------||------------------ + + + || num of individual results || + operator is || || final result is + || T | F | E | U | NE | NA || +---------------||-----------------------------||------------------ + || 1 | 0+ | 0 | 0 | 0 | 0+ || True + || 2+ | 0+ | 0+ | 0+ | 0+ | 0+ || ** False ** + || 0 | 1+ | 0 | 0 | 0 | 0+ || ** False ** + ONE ||0,1 | 0+ | 1+ | 0+ | 0+ | 0+ || Error + ||0,1 | 0+ | 0 | 1+ | 0+ | 0+ || Unknown + ||0,1 | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated + || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable +---------------||-----------------------------||------------------ + + + || num of individual results || + operator is || || final result is + || T | F | E | U | NE | NA || +---------------||-----------------------------||------------------ + || 1+ | 0+ | 0+ | 0+ | 0+ | 0+ || True + || 0 | 1+ | 0 | 0 | 0 | 0+ || False + OR || 0 | 0+ | 1+ | 0+ | 0+ | 0+ || Error + || 0 | 0+ | 0 | 1+ | 0+ | 0+ || Unknown + || 0 | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated + || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable +---------------||-----------------------------||------------------ + + + || num of individual results || + operator is || || final result is + || T | F | E | U | NE | NA || +---------------||-----------------------------||------------------ + ||odd | 0+ | 0 | 0 | 0 | 0+ || True + ||even| 0+ | 0 | 0 | 0 | 0+ || False + XOR || 0+ | 0+ | 1+ | 0+ | 0+ | 0+ || Error + || 0+ | 0+ | 0 | 1+ | 0+ | 0+ || Unknown + || 0+ | 0+ | 0 | 0 | 1+ | 0+ || Not Evaluated + || 0 | 0 | 0 | 0 | 0 | 1+ || Not Applicable +---------------||-----------------------------||------------------ + + + + + + + The AND operator produces a true result if every argument is true. If one or more arguments are false, the result of the AND is false. If one or more of the arguments are unknown, and if none of the arguments are false, then the AND operator produces a result of unknown. + + + + + The ONE operator produces a true result if one and only one argument is true. If there are more than argument is true (or if there are no true arguments), the result of the ONE is false. If one or more of the arguments are unknown, then the ONE operator produces a result of unknown. + + + + + The OR operator produces a true result if one or more arguments is true. If every argument is false, the result of the OR is false. If one or more of the arguments are unknown and if none of arguments are true, then the OR operator produces a result of unknown. + + + + + XOR is defined to be true if an odd number of its arguments are true, and false otherwise. If any of the arguments are unknown, then the XOR operator produces a result of unknown. + + + + + + + + + + Define the format for acceptable OVAL Definition ids. An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'def', and ending with an integer. + + + + + + + + Define the format for acceptable OVAL Object ids. An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'obj', and ending with an integer. + + + + + + + + Define the format for acceptable OVAL State ids. An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'ste', and ending with an integer. + + + + + + + + Define the format for acceptable OVAL Test ids. An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'tst', and ending with an integer. + + + + + + + + Define the format for acceptable OVAL Variable ids. An urn format is used with the id starting with the word oval followed by a unique string, followed by the three letter code 'var', and ending with an integer. + + + + + + + + Define the format for acceptable OVAL Item ids. The format is an integer. An item id is used to identify the different items found in an OVAL System Characteristics file. + + + + + + + + + The EmptyStringType simple type is a restriction of the built-in string simpleType. The only allowed string is the empty string with a length of zero. This type is used by certain elements to allow empty content when non-string data is accepted. See the EntityIntType in the OVAL Definition Schema for an example of its use. + + + + + + + + The NonEmptyStringType simple type is a restriction of the built-in string simpleType. Empty strings are not allowed. This type is used by comment attributes where an empty value is not allowed. + + + + + + + + + diff --git a/stix_validator/schema/external/oval_5.10/oval-definitions-schema.xsd b/stix_validator/schema/external/oval_5.10/oval-definitions-schema.xsd new file mode 100755 index 0000000..b81b5cf --- /dev/null +++ b/stix_validator/schema/external/oval_5.10/oval-definitions-schema.xsd @@ -0,0 +1,1608 @@ + + + + + + The following is a description of the elements, types, and attributes that compose the core schema for encoding Open Vulnerability and Assessment Language (OVAL) Definitions. Some of the objects defined here are extended and enhanced by individual component schemas, which are described in separate documents. Each of the elements, types, and attributes that make up the Core Definition Schema are described in detail and should provide the information necessary to understand what each represents. This document is intended for developers and assumes some familiarity with XML. A high level description of the interaction between these objects is not outlined here. + The OVAL Schema is maintained by The MITRE Corporation and developed by the public OVAL Community. For more information, including how to get involved in the project and how to submit change requests, please visit the OVAL website at http://oval.mitre.org. + + Core Definition + 5.10.1 + 1/27/2012 1:22:32 PM + Copyright (c) 2002-2012, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the OVAL License located at http://oval.mitre.org/oval/about/termsofuse.html. See the OVAL License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the OVAL Schema, this license header must be included. + + + + + + + + + + The oval_definitions element is the root of an OVAL Definition Document. Its purpose is to bind together the major sections of a document - generator, definitions, tests, objects, states, and variables - which are the children of the root element. + + + + A valid OVAL Definition document must contain at least one definitions, tests, objects, states, or variables element. The optional definitions, tests, objects, states, and variables sections define the specific characteristics that should be evaluated on a system to determine the truth values of the OVAL Definition Document. To be valid though, at least one definitions, tests, objects, states, or variables element must be present. + + + + + + + + + The required generator section provides information about when the definition file was compiled and under what version. + + + + + The optional definitions section contains 1 or more definitions. + + + + + The optional tests section contains 1 or more tests. + + + + + The optional objects section contains 1 or more objects. + + + + + The optional states section contains 1 or more states. + + + + + The optional variables section contains 1 or more variables. + + + + + The optional Signature element allows an XML Signature as defined by the W3C to be attached to the document. This allows authentication and data integrity to be provided to the user. Enveloped signatures are supported. More information about the official W3C Recommendation regarding XML digital signatures can be found at http://www.w3.org/TR/xmldsig-core/. + + + + + + + Enforce uniqueness amongst the ids differentiating the individual definition elements. + + + + + + + Enforce uniqueness amongst the ids differentiating the individual test elements. + + + + + + + Enforce uniqueness amongst the ids differentiating the individual object elements. + + + + + + + Enforce uniqueness amongst the ids differentiating the individual state elements. + + + + + + + Enforce uniqueness amongst the ids differentiating the individual variable elements. + + + + + + + Requires each definition reference to refer to a valid definition id. + + + + + + + Requires each test reference to refer to a valid test id. + + + + + + + Requires each object reference to refer to a valid object id. + + + + + + + Requires each state reference to refer to a valid state id. + + + + + + + Requires each variable reference to refer to a valid variable id. + + + + + + + Require each object reference in a set element to refer to a valid object id. + + + + + + + Require each filter in a set element to refer to a valid state id. + + + + + + + + + + + + + + + The DefinitionsType complex type is a container for one or more definition elements. Each definition element describes a single OVAL Definition. Please refer to the description of the DefinitionType for more information about an individual definition. + + + + + + + + The definition element represents the globally defined element of type DefinitionType. For more information please see the documentation on the DefinitionType. + + + + + The DefinitionType defines a single OVAL Definition. A definition is the key structure in OVAL. It is analogous to the logical sentence or proposition: if a computer's state matches the configuration parameters laid out in the criteria, then that computer exhibits the state described. The DefinitionType contains a section for various metadata related elements that describe the definition. This includes a description, version, affected system types, and reference information. The notes section of a definition should be used to hold information that might be helpful to someone examining the technical aspects of the definition. For example, why certain tests have been included in the criteria, or maybe a link to where further information can be found. The DefinitionType also (unless the definition is deprecated) contains a criteria child element that joins individual tests together with a logical operator to specify the specific computer state being described. + The required id attribute is the OVAL-ID of the Definition. The form of an OVAL-ID must follow the specific format described by the oval:DefinitionIDPattern. The required version attribute holds the current version of the definition. Versions are integers, starting at 1 and incrementing every time a definition is modified. The required class attribute indicates the specific class to which the definition belongs. The class gives a hint to a user so they can know what the definition writer is trying to say. See the definition of oval-def:ClassEnumeration for more information about the different valid classes. The optional deprecated attribute signifies that an id is no longer to be used or referenced but the information has been kept around for historic purposes. + When the deprecated attribute is set to true, the definition is considered to be deprecated. The criteria child element of a deprecated definition is optional. If a deprecated definition does not contain a criteria child element, the definition must evaluate to "not evaluated". If a deprecated definition contains a criteria child element, an interpreter should evaluate the definition as if it were not deprecated, but an interpreter may evaluate the definition to "not evaluated". + + + + A valid OVAL Definition must contain a criteria unless the definition is a deprecated definition. + + + + + + + + + + Each affected element must have a unique family attribute value. + + + + + + + + + + + + + + + + The MetadataType complex type contains all the metadata available to an OVAL Definition. This metadata is for informational purposes only and is not part of the criteria used to evaluate machine state. The required title child element holds a short string that is used to quickly identify the definition to a human user. The affected metadata item contains information about the system(s) for which the definition has been written. Remember that this is just metadata and not part of the criteria. Please refer to the AffectedType description for more information. The required description element contains a textual description of the configuration state being addressed by the OVAL Definition. In the case of a definition from the vulnerability class, the reference is usually the Common Vulnerability and Exposures (CVE) Identifier, and this description field corresponds with the CVE description. + Additional metadata is also allowed although it is not part of the official OVAL Schema. Individual organizations can place metadata items that they feel are important and these will be skipped during the validation. All OVAL really cares about is that the stated metadata items are there. + + + + + + + Each affected platform element must have a unique value. + + + + + + + Each affected product element must have a unique value. + + + + + + + + + + + + + + Each OVAL Definition is written to evaluate a certain type of system(s). The family, platform(s), and product(s) of this target are described by the AffectedType whose main purpose is to provide hints for tools using OVAL Definitions. For instance, to help a reporting tool only use Windows definitions, or to preselect only Red Hat definitions to be evaluated. Note, the inclusion of a particular platform or product does not mean the definition is physically checking for the existence of the platform or product. For the actual test to be performed, the correct test must still be included in the definition's criteria section. + The AffectedType complex type details the specific system, application, subsystem, library, etc. for which a definition has been written. If a definition is not tied to a specific product, then this element should not be included. The absence of the platform or product element can be thought of as definition applying to all platforms or products. The inclusion of a particular platform or product does not mean the definition is physically checking for the existence of the platform or product. For the actual test to be performed, the correct test must still be included in the definition's criteria section. To increase the utility of this element, care should be taken when assigning and using strings for product names. The schema places no restrictions on the values that can be assigned, potentially leading to many different representations of the same value. For example, 'Internet Explorer' and 'IE' might be used to refer to the same product. The current convention is to fully spell out all terms, and avoid the use of abbreviations at all costs. + Please note that the AffectedType will change in future versions of OVAL in order to support the Common Platform Enumeration (CPE). + + + + + + + + + + The ReferenceType complex type links the OVAL Definition to a definitive external reference. For example, CVE Identifiers are used for referencing vulnerabilities. The intended purpose for this reference is to link the definition to a variety of other sources that address the same issue being specified by the OVAL Definition. + The required source attribute specifies where the reference is coming from. In other words, it identifies the reference repository being used. The required ref_id attribute is the external id of the reference. The optional ref_url attribute is the URL to the reference. + + + + + + + + The NotesType complex type is a container for one or more note child elements. Each note contains some information about the definition or tests that it references. A note may record an unresolved question about the definition or test or present the reason as to why a particular approach was taken. + + + + + + + + The CriteriaType complex type describes a container for a set of sub criteria, criteria, criterion, or extend_definition elements allowing complex logical trees to be constructed. Each referenced test is represented by a criterion element. Please refer to the description of the CriterionType for more information about and individual criterion element. The optional extend_definition element allows existing definitions to be included in the criteria. Refer to the description of the ExtendDefinitionType for more information. + The required operator attribute provides the logical operator that binds the different statements inside a criteria together. The optional negate attribute signifies that the result of the criteria as a whole should be negated during analysis. For example, consider a criteria that evaluates to TRUE if certain software is installed. By negating this test, it now evaluates to TRUE if the software is NOT installed. The optional comment attribute provides a short description of the criteria. + The optional applicability_check attribute provides a Boolean flag that when true indicates that the criteria is being used to determine whether the OVAL Definition applies to a given system. + + + + + + + + + + + + + + The CriterionType complex type identifies a specific test to be included in the definition's criteria. + The required test_ref attribute is the actual id of the test being referenced. The optional negate attribute signifies that the result of an individual test should be negated during analysis. For example, consider a test that evaluates to TRUE if a specific patch is installed. By negating this test, it now evaluates to TRUE if the patch is NOT installed. The optional comment attribute provides a short description of the specified test and should mirror the comment attribute of the actual test. + The optional applicability_check attribute provides a Boolean flag that when true indicates that the criterion is being used to determine whether the OVAL Definition applies to a given system. + + + + + + + + + The ExtendDefinitionType complex type allows existing definitions to be extended by another definition. This works by evaluating the extended definition and then using the result within the logical context of the extending definition. + The required definition_ref attribute is the actual id of the definition being extended. The optional negate attribute signifies that the result of an extended definition should be negated during analysis. For example, consider a definition that evaluates TRUE if certainsoftware is installed. By negating the definition, it now evaluates to TRUE if the software is NOT installed. The optional comment attribute provides a short description of the specified definition and should mirror the title metadata of the extended definition. + The optional applicability_check attribute provides a Boolean flag that when true indicates that the extend_definition is being used to determine whether the OVAL Definition applies to a given system. + + + + + + + + + + + + The TestsType complex type is a container for one or more test child elements. Each test element describes a single OVAL Test. Please refer to the description of the TestType for more information about an individual test. + + + + + + + + The test element is an abstract element that is meant to be extended (via substitution groups) by the individual tests found in the component schemas. An OVAL Test is used to compare an object(s) against a defined state. An actual test element is not valid. The use of this abstract class simplifies the OVAL schema by allowing individual tests to inherit the optional notes child element, and the id and comment attributes from the base TestType. Please refer to the description of the TestType complex type for more information. + + + + + The base type of every test includes an optional notes element and several attributes. The notes section of a test should be used to hold information that might be helpful to someone examining the technical aspects of the test. For example, why certain values have been used by the test, or maybe a link to where further information can be found. Please refer to the description of the NotesType complex type for more information about the notes element. The required comment attribute provides a short description of the test. The optional deprecated attribute signifies that an id is no longer to be used or referenced but the information has been kept around for historic purposes. + The required id attribute uniquely identifies each test, and must conform to the format specified by the TestIdPattern simple type. The required version attribute holds the current version of the test. Versions are integers, starting at 1 and incrementing every time a test is modified. + The optional check_existence attribute specifies how many items in the set defined by the OVAL Object must exist for the test to evaluate to true. The default value for this attribute is 'at_least_one_exists' indicating that by default the test may evaluate to true if at least one item defined by the OVAL Object exists on the system. For example, if a value of 'all_exist' is given, every item defined by the OVAL Object must exist on the system for the test to evaluate to true. If the OVAL Object uses a variable reference, then every value of that variable must exist. Note that a pattern match defines a unique set of matching items found on a system. So when check_existence = 'all_exist' and a regex matches anything on a system the test will evaluate to true (since all matching objects on the system were found on the system). When check_existence = 'all_exist' and a regex does not match anything on a system the test will evaluate to false. + The required check attribute specifies how many items in the set defined by the OVAL Object (ignoring items with a status of Does Not Exist) must satisfy the state requirements. For example, should the test check that all matching files have a specified version or that at least one file has the specified version? The valid check values are explained in the description of the CheckEnumeration simple type. Note that if the test does not contain any references to OVAL States, then the check attribute has no meaning and can be ignored during evaluation. + An OVAL Test evaluates to true if both the check_existence and check attributes are satisfied during evaluation. The evaluation result for a test is determined by first evaluating the check_existence attribute. If the result of evaluating the check_existence attribute is true then the check attribute is evaluated. An interpreter may choose to always evaluate both the check_existence and the check attributes, but once the check_existence attribute evaluation has resulted in false the overall test result after evaluating the check attribute will not be affected. + The optional state_operator attribute provides the logical operator that combines the evaluation results from each referenced state on a per item basis. Each matching item is compared to each referenced state. The result of comparing each state to a single item is combined based on the specified state_operator value to determine one result for each item. Finally, the results for each item are combined based on the specified check value. Note that if the test does not contain any references to OVAL States, then the state_operator attribute has no meaning and can be ignored during evaluation. Referencing multiple states in one test allows ranges of possible values to be expressed. For example, one state can check that a value greater than 8 is found and another state can check that a value of less than 16 is found. In this example the referenced states are combined with a state_operator = 'AND' indicating that the conditions of all referenced states must be satisfied and that the value must be between 8 AND 16. The valid state_operation values are explained in the description of the OperatorEnumeration simple type. + + + + - No state should be referenced when check_existence has a value of 'none_exist'. + + + + + + + + + + + + + + + + + + + The ObjectRefType complex type defines an object reference to be used by OVAL Tests that are defined in the component schemas. The required object_ref attribute specifies the id of the OVAL Object being referenced. + + + + + + The StateRefType complex type defines a state reference to be used by OVAL Tests that are defined in the component schemas. The required state_ref attribute specifies the id of the OVAL State being referenced. + + + + + + + + + The ObjectsType complex type is a container for one or more object child elements. Each object element provides details that define a unique set of matching items to be used by an OVAL Test. Please refer to the description of the object element for more information about an individual object. + + + + + + + + The object element is an abstract element that is meant to be extended (via substitution groups) by the objects found in the component schemas. An actual object element is not valid. The use of this abstract element simplifies the OVAL schema by allowing individual objects to inherit any common elements and attributes from the base ObjectType. Please refer to the description of the ObjectType complex type for more information. + An object is used to identify a set of items to collect. The author of a schema object must define sufficient object entities to allow a user to identify a unique item to be collected. + A simple object typically results in a single file, process, etc being identified. But through the use of pattern matches, sets, and variables, multiple matching items can be identified. The set of items matching the object can then be used by an OVAL test and compared against an OVAL state. + + + + + The base type of every object includes an optional notes element. The notes element of an object should be used to hold information that might be helpful to someone examining the technical aspects of the object. For example, why certain values have been used, or maybe a link to where further information can be found. Please refer to the description of the NotesType complex type for more information about the notes element. + The required id attribute uniquely identifies each object, and must conform to the format specified by the ObjectIdPattern simple type. The required version attribute holds the current version of the object element. Versions are integers, starting at 1 and incrementing every time an object is modified. The optional comment attribute provides a short description of the object. The optional deprecated attribute signifies that an id is no longer to be used or referenced but the information has been kept around for historic purposes. + + + + + + + + + + + + + The set element enables complex objects to be described. It is a recursive element in that each set element can contain additional set elements as children. Each set element defines characteristics that produce a matching unique set of items. This set of items is defined by one or two references to OVAL Objects that provide the criteria needed to collect a set of system items. These items can have one or more filters applied to allow a subset of those items to be specifically included or excluded from the overall set of items. + The set element's object_reference refers to an existing OVAL Object. The set element's filter element provides a reference to an existing OVAL State and includes an optional action attribute. The filter's action attribute allows the author to specify whether matching items should be included or excluded from the overall set. The default filter action is to exclude all matching items. In other words, the filter can be thought of filtering items out by default. + Each filter is applied to the items identified by each OVAL Object before the set_operator is applied. For example, if an object_reference points to an OVAL Object that identifies every file in a certain directory, a filter might be set up to limit the object set to only those files with a size less than 10 KB. If multiple filters are provided, then each filter is applied to the set of items identified by the OVAL Object. Care must be taken to ensure that conflicting filters are not applied. It is possible to exclude all items with a size of 10 KB and then include only items with a size of 10 KB. This example would result in the empty set. + The required set_operator attribute defines how different child sets are combined to form the overall unique set of objects. For example, does one take the union of different sets or the intersection? For a description of the valid values please refer to the SetOperatorEnumeration simple type. + + + + - Each object referenced by the set must be of the same type as parent object + + + - Each object referenced by the set must be of the same type as parent object + + + - Each object referenced by the set must be of the same type as parent object + + + + + + + + + + + + + + + + + + + + The filter element provides a reference to an existing OVAL State and includes an optional action attribute. The action attribute is used to specify whether items that match the referenced OVAL State will be included in the resulting set or excluded from the resulting set. + + + + + + + + + + + + + + + The StatesType complex type is a container for one or more state child elements. Each state provides details about specific characteristics that can be used during an evaluation of an object. Please refer to the description of the state element for more information about an individual state. + + + + + + + + The state element is an abstract element that is meant to be extended (via substitution groups) by the states found in the component schemas. An actual state element is not valid. The use of this abstract class simplifies the OVAL schema by allowing individual states to inherit the optional notes child element, and the id and operator attributes from the base StateType. Please refer to the description of the StateType complex type for more information. + An OVAL State is a collection of one or more characteristics pertaining to a specific object type. The OVAL State is used by an OVAL Test to determine if a unique set of items identified on a system meet certain characteristics. + + + + + The base type of every state includes an optional notes element and two attributes. The notes section of a state should be used to hold information that might be helpful to someone examining the technical aspects of the state. For example, why certain values have been used by the state, or maybe a link to where further information can be found. Please refer to the description of the NotesType complex type for more information about the notes element. + The required id attribute uniquely identifies each state, and must conform to the format specified by the StateIdPattern simple type. The required version attribute holds the current version of the state. Versions are integers, starting at 1 and incrementing every time a state is modified. The required operator attribute provides the logical operator that binds the different characteristics inside a state together. The optional comment attribute provides a short description of the state. The optional deprecated attribute signifies that an id is no longer to be used or referenced but the information has been kept around for historic purposes. + When evaluating a particular state against an object, one should evaluate each individual entity separately. The individual results are then combined by the operator to produce an overall result. This process holds true even when there are multiple instances of the same entity. Evaluate each instance separately, taking the entity check attribute into account, and then combine everything using the operator. + + + + + + + + + + + + + + + + + The VariablesType complex type is a container for one or more variable child elements. Each variable element is a way to define one or more values to be obtained at the time a definition is evaluated. + + + + + + + + The variable element is an abstract element that is meant to be extended (via substitution groups) by the different types of variables. An actual variable element is not valid. The different variable types describe different sources for obtaining a value(s) for the variable. There are currently three types of variables; local, external, and constant. Please refer to the description of each one for more specific information. The value(s) of a variable is treated as if it were inserted where referenced. One of the main benefits of variables is that they allow tests to evaluate user-defined policy. For example, an OVAL Test might check to see if a password is at least a certain number of characters long, but this number depends upon the individual policy of the user. To solve this, the test for password length can be written to refer to a variable element that defines the length. + If a variable defines an array of values, any entity that references the variable will evaluate to true depending on the value of the var_check attribute. For example, if an entity 'size' with an operation of 'less than' references a variable that returns five different integers, and the var_check attribute has a value of 'all', then the 'size' entity returns true only if the actual size is less than each of the five integers defined by the variable. If a variable does not return any value, then an error should be reported during OVAL analysis. + + + + + The VariableType complex type defines attributes associated with each OVAL Variable. The required id attribute uniquely identifies each variable, and must conform to the format specified by the VariableIDPattern simple type. The required version attribute holds the current version of the variable. Versions are integers, starting at 1 and incrementing every time a variable is modified. The required comment attribute provides a short description of the variable. The optional deprecated attribute signifies that an id is no longer to be used or referenced but the information has been kept around for historic purposes. + The required datatype attribute specifies the type of value being defined. The set of values identified by a variable must comply with the specified datatype, otherwise an error should be reported. Please see the DatatypeEnumeration for details about each valid datatype. For example, if the datatype of the variable is specified as boolean then the value(s) returned by the component / function should be "true", "false", "1", or "0". + Note that the 'record' datatype is not permitted on variables. + + + + + + + + + Note that the 'record' datatype is not permitted on variables. + + + + + + + + The external_variable element extends the VariableType and defines a variable with some external source. The actual value(s) for the variable is not provided within the OVAL file, but rather it is retrieved during the evaluation of the OVAL Definition from an external source. An unbounded set of possible-value and possible_restriction child elements can be specified that together specify the list of all possible values that an external source is allowed to supply for the external variable. In other words, the value assigned by an external source must match one of the possible_value or possible_restriction elements specified. Each possible_value element contains a single value that could be assigned to the given external_variable while each possible_restriction element outlines a range of possible values. Note that it is not necessary to declare a variable's possible values, but the option is available if desired. If no possible child elements are specified, then the valid values are only bound to the specified datatype of the external variable. Please refer to the description of the PossibleValueType and PossibleRestrictionType complex types for more information. + + + + + + + + + + + + + + + The PossibleValueType complex type is used to outline a single expected value of an external variable. The required hint attribute gives a short description of what the value means or represents. + + + + + + + + + + The PossibleRestrictionType complex type outlines a range of possible expected value of an external variable. Each possible_restriction element contains an unbounded list of child restriction elements that each specify a range that an actual value may fall in. For example, a restriction element may specify that a value must be less than 10. When multiple restriction elements are present, a valid possible value would have to meet every restriction. One can think of the possible_value and possible_restriction elements as an OR'd list of possible values, and the restriction elements as an AND'd list of value descriptions. Please refer to the description of the RestrictionType complex type for more information. The required hint attribute gives a short description of what the value means or represents. + + + + + + + + + The RestrictionType complex type outlines a restriction that is placed on expected values for an external variable. For example, a possible value may be restricted to a integer less than 10. Please refer to the operationEnumeration simple type for a description of the valid operations. The required hint attribute gives a short description of what the value means or represents. + + + + + + + + + + The constant_variable element extends the VariableType and defines a variable with a constant value(s). Each constant_variable defines either a single value or an array of values to be used throughout the evaluation of the OVAL Definition File in which it has been defined. Constant variables cannot be over-ridden by an external source. The actual value of a constant variable is defined by the required value child element. An array of values can be specified by including multiple instances of the value element. Please refer to the description of the ValueType complex type for more information. + + + + + + + + + + + + + + The ValueType complex type holds the actual value of the variable when dealing with a constant variable. This value should be used by all tests that reference this variable. The value cannot be over-ridden by an external source. + + + + + + + + The local_variable element extends the VariableType and defines a variable with some local source. The actual value(s) for the variable is not provided in the OVAL Definition document but rather it is retrieved during the evaluation of the OVAL Definition. Each local variable is defined by either a single component or a complex function, meaning that a value can be as simple as a literal string or as complex as multiple registry keys concatenated together. Note that if an individual component is used and it returns multiple values, then there will be multiple values associated with the local_variable. For example, if an object_component is used and it references a file object that identifies a set of 5 files, then the local variable would represent these 5 values. Please refer to the description of the ComponentGroup for more information. + + + + + + + + + + + + + + Any value that is pulled directly off the local system is defined by the basic component element. For example, the name of a user or the value of a registry key. Please refer to the definition of the ObjectComponentType for more information. A value can also be obtained from another variable. The variable element identifies a variable id to pull a value(s) from. Please refer to the definition of the VariableComponentType for more information. Literal values can also be specified. + + + + + + + + + + + The LiteralComponentType complex type defines a literal value to be used as a component. The optional datatype attribute defines the type of data expected. The default datatype is 'string'. + + + + - The 'record' datatype is prohibited on variables. + + + + + + + + + + + + + + The ObjectComponentType complex type defines a specific value or set of values on the local system to obtain. + The required object_ref attribute provides a reference to an existing OVAL Object declaration. The referenced OVAL Object specifies a set of OVAL Items to collect. Note that an OVAL Object might identify 0, 1, or many OVAL Items on a system. If no items are found on the system then an error should be reported when determining the value of an ObjectComponentType. If 1 or more OVAL Items are found then each OVAL Item will be considered and the ObjectComponentType may have one or more values. + The required item_field attribute specifies the name of the entity whose value will be retrieved from each OVAL Item collected by the referenced OVAL Object. For example, if the object_ref references a win-def:file_object, the item_field may specify the 'version' entity as the field to use as the value of the ObjectComponentType. Note that an OVAL Item may have 0, 1, or many entities whose name matches the specified item_field value. If an entity is not found with a name that matches the value of the item_field an error should be reported when determining the value of an ObjectComponentType. If 1 or more matching entities are found in a single OVAL Item the value of the ObjectComponentType is the list of the values from each of the matching entities. + The optional record_field attribute specifies the name of a field in a record entity in an OVAL Item. The record_field attribute allows the value of a specific field to be retrieved from an entity with a datatype of 'record'. If a field with a matching name attribute value is not found in the referenced OVAL Item entity an error should be reported when determining the value of the ObjectComponentType. + + + + + + + + The VariableComponentType complex type defines a specific value obtained by looking at the value of another OVAL Variable. The required var_ref attribute provides a reference to the variable. One must make sure that the variable reference does not point to the parent variable that uses this component to avoid a race condition. + + + + + + Complex functions have been defined that help determine how to manipulate specific values. These functions can be nested together to form complex statements. Each function is designed to work on a specific type of data. If the data being worked on is not of the correct type, a cast should be attempted before reporting an error. For example, if a concat function includes a registry component that returns an integer, then the integer should be cast as a string in order to work with the concat function. Note that if the operation being applied to the variable by the calling entity is "pattern match", then all the functions are performed before the regular expression is evaluated. In short, the variable would produce a value as normal and then any pattern match operation would be performed. It is also important to note that when using these functions with sub-components that return multiple values that the operation will be performed on the Cartesian product of the components and the result is an array of values. For example, assume a local_variable specifies the arithmetic function with an arithmetic_operation of "add" and has two sub-components under this function: the first component returns multiple values "1" and "2", and the second component returns multiple values "3" and "4" and "5". The local_variable element would be evaluated to have six values: 1+3, 1+4, 1+5, 2+3, 2+4, and 2+5. Please refer to the description of a specific function for more details about it. + + + + + + + + + + + + + + + + + + The arithmetic function takes two or more integer or float components and performs a basic mathematical function on them. The result of this function is a single integer or float unless one of the components returns multiple values. In this case the specified arithmetic function would be performed multiple times and the end result would be an array of values for the local variable. For example assume a local_variable specifies the arithmetic function with an arithmetic_operation of "add" and has two sub-components under this function: the first component returns multiple values "1" and "2", and the second component returns multiple values "3" and "4" and "5". The local_variable element would be evaluated to have six values: 1+3, 1+4, 1+5, 2+3, 2+4, and 2+5. + Note that if both an integer and float components are used then the result is a float. + + + + A literal_component used by an arithmetic function must have a datatype of float or int. + + + + The variable referenced by the arithmetic function must have a datatype of float or int. + + + + + + + + + + + + The begin function takes a single string component and defines a character (or string) that the component string should start with. The character attribute defines the specific character (or string). The character (or string) is only added to the component string if the component string does not already start with the specified character (or string). If the component string does not start with the specified character (or string) the entire character (or string) will be prepended to the component string.. + + + + A literal_component used by the begin function must have a datatype of string. + + + + The variable referenced by the begin function must have a datatype of string. + + + + + + + + + + + + The concat function takes two or more components and concatenates them together to form a single string. The first component makes up the beginning of the resulting string and any following components are added to the end it. If one of the components returns multiple values then the concat function would be performed multiple times and the end result would be an array of values for the local variable. For example assume a local variable has two sub-components: a basic component element returns the values "abc" and "def", and a literal component element that has a value of "xyz". The local_variable element would be evaluated to have two values, "abcxyz" and "defxyz". If one of the components does not exist, then the result of the concat operation should be does not exist. + + Below is a chart that specifies how to classify the flag status of a variable using the concat function during evaluation when multiple components are supplied. Both the object and variable component are indirectly associated with collected objects in a system characteristics file. These objects could have been completely collected from the system, or there might have been some type of error that led to the object not being collected, or maybe only a part of the object set was collected. This flag status is important as OVAL Objects or OVAL States that are working with a variable (through the var_ref attribute on an entity) can use this information to report more accurate results. For example, an OVAL Test with a check attribute of 'at least one' that specifies an object with a variable reference, might be able to produce a valid result based on an incomplete object set as long as one of the objects in the set is true. + + || num of components with flag || + || || resulting flag is + || E | C | I | DNE | NC | NA || +------||-----------------------------------||------------------ + || 1+ | 0+ | 0+ | 0+ | 0+ | 0+ || Error + || 0 | 1+ | 0 | 0 | 0 | 0 || Complete + || 0 | 0+ | 1+ | 0 | 0 | 0 || Incomplete + || 0 | 0+ | 0+ | 1+ | 0 | 0 || Does Not Exist + || 0 | 0+ | 0+ | 0+ | 1+ | 0 || Not Collected + || 0 | 0+ | 0+ | 0+ | 0+ | 1+ || Not Applicable +------||-----------------------------------||------------------ + + + + A literal_component used by the concat function must have a datatype of string. + + + + The variable referenced by the concat function must have a datatype of string. + + + + + + + + + + + The end function takes a single string component and defines a character (or string) that the component string should end with. The character attribute defines the specific character (or string). The character (or string) is only added to the component string if the component string does not already end with the specified character (or string). If the desired end character is a string, then the entire end string must exist at the end if the component string. If the entire end string is not present then the entire end string is appended to the component string. + + + + A literal_component used by the end function must have a datatype of string. + + + + The variable referenced by the end function must have a datatype of string. + + + + + + + + + + + + The escape_regex function takes a single string component and escapes all of the regular expression characters. For example, the string '(\.test_string*)?' will evaluate to '\(\\\.test_string\*\)\?'. The purpose for this is that many times, a component used in pattern match needs to be treated as a literal string and not a regular expression. For example, assume a basic component element that identifies a file path that is held in the Windows registry. This path is a string that might contain regular expression characters. These characters are likely not intended to be treated as regular expression characters and need to be escaped. This function allows a definition writer to mark convert the values of components to regular expression format. + Note that when using regular expressions, OVAL supports a common subset of the regular expression character classes, operations, expressions and other lexical tokens defined within Perl 5's regular expression specification. For more information on the supported regular expression syntax in OVAL see: http://oval.mitre.org/language/about/re_support_5.6.html. + + + + A literal_component used by the escape_regex function must have a datatype of string. + + + + The variable referenced by the escape_regex function must have a datatype of string. + + + + + + + + + + + The split function takes a single string component and turns it into multiple values based on a delimiter string. For example, assume that a basic component element returns the value "a-b-c-d" to the split function with the delimiter set to "-". The local_variable element would be evaluated to have four values "a", "b", "c", and "d". If the basic component returns a value that begins, or ends, with a delimiter, the local_variable element would contain empty string values at the beginning, or end, of the set of values returned for that string component. For example, if the delimiter is "-", and the basic component element returns the value "-a-a-", the local_variable element would be evaluated to have four values "", "a", "a", and "". Likewise, if the basic component element returns a value that contains adjacent delimiters such as "---", the local_variable element would be evaluated to have four values "", "", "", and "". Lastly, if the basic component element used by the split function returns multiple values, then the split function is performed multiple times, and all of the results, from each of the split functions, are returned. + + + + A literal_component used by the split function must have a datatype of string. + + + + The variable referenced by the split function must have a datatype of string. + + + + + + + + + + + + The substring function takes a single string component and produces a single value that contains a portion of the original string. The substring_start attribute defines the starting position in the original string. To include the first character of the string, the start position would be 1. A value less than 1 also means that the start position would be 1. If the substring_start attribute has value greater than the length of the original string an error should be reported. The substring_length attribute defines how many characters after, and including, the starting character to include. A substring_length value greater than the actual length of the string, or a negative value, means to include all of the characters after the starting character. For example, assume a basic component element that returns the value "abcdefg" with a substring_start value of 3 and a substring_length value of 2. The local_variable element would evaluate to have a single value of "cd". If the string component used by the substring function returns multiple values, then the substring operation is performed multiple times and results in multiple values for the component. + + + + A literal_component used by the substring function must have a datatype of string. + + + + The variable referenced by the substring function must have a datatype of string. + + + + + + + + + + + + + The time_difference function calculates the difference in seconds between date-time values. If one component is specified, the values of that component are subtracted from the current time (UTC). If two components are specified, the value of the second component is subtracted from the value of the first component. If the component(s) contain multiple values, the operation is performed multiple times on the Cartesian product of the component(s) and the result is an array of time difference values. For example, assume a local_variable specifies the time_difference function and has two sub-components under this function: the first component returns multiple values "04/02/2009" and "04/03/2009", and the second component returns multiple values "02/02/2005" and "02/03/2005" and "02/04/2005". The local_variable element would be evaluated to have six values: (ToSeconds("04/02/2009") - ToSeconds("02/02/2005")), (ToSeconds("04/02/2009") - ToSeconds("02/03/2005")), (ToSeconds("04/02/2009") - ToSeconds("02/04/2005")), (ToSeconds("04/03/2009") - ToSeconds("02/02/2005")), (ToSeconds("04/03/2009") - ToSeconds("02/03/2005")), and (ToSeconds("04/03/2009") - ToSeconds("02/04/2005")). + The date-time format of each component is determined by the two format attributes. The format1 attribute applies to the first component, and the format2 attribute applies to the second component. Valid values for the attributes are 'win_filetime', 'seconds_since_epoch', 'day_month_year', 'year_month_day', and 'month_day_year'. Please see the DateTimeFormatEnumeration for more information about each of these values. If an input value is not understood, the result is an error. If only one input is specified, specify the format with the format2 attribute, as the first input is considered to be the implied 'current time' input. + Note that the datatype associated with the components should be 'string' or 'int' depending on which date time format is specified. The result of this function though is always an integer. + + + + A literal_component used by the time_difference function must have a datatype of string or int. + + + + The variable referenced by the time_difference function must have a datatype of string or int. + + + + + + + + + + + + + The regex_capture function captures a single substring from a string component. The 'pattern' attribute provides a regular expression that must contain a single subexpression (using parentheses). The first match of the subexpression is considered the captured substring. For example, the pattern ^abc(.*)xyz$ would capture a substring from each of the string component's values if the value starts with abc and ends with xyz. In this case the subexpression would be all the characters that exist in between the abc and the xyz. If more than one subexpression is supplied only the first match is considered. If more than one match is identified by a single subexpression only the first match is considered. If no matches are found or a subexpression is not supplied the function will evaluate to an empty string. Note that subexpressions match the longest possible substrings. + Note that when using regular expressions, OVAL supports a common subset of the regular expression character classes, operations, expressions and other lexical tokens defined within Perl 5's regular expression specification. For more information on the supported regular expression syntax in OVAL see: http://oval.mitre.org/language/about/re_support_5.6.html. + + + + A literal_component used by the regex_capture function must have a datatype of string. + + + + The variable referenced by the regex_capture function must have a datatype of string. + + + + + + + + + + + + The unique function takes one or more components and removes any duplicate value from the set of components. All components used in the unique function will be treated as strings. For example, assume that three components exist, one that contains a string value of 'foo', and two of which both resolve to the string value 'bar'. Applying the unique function to these three components resolves to a local_variable with two string values, 'foo' and 'bar'. Additionally, if any of the components referenced by the unique function evaluate to multiple values, then those values are used in the unique calculation. For example, assume that there are two components, one of which resolves to a single string value, 'foo', the other of which resolves to two string values, 'foo' and 'bar'. If the unique function is used to remove duplicates from these two components, the function will resolve to a local_variable with two string values, 'foo' and 'bar'. + + + + + + + + The count function takes one or more components and returns the count of all of the values represented by the components. For example, assume that two variables exist, each with a single value. By applying the count function against two variable components that resolve to the two variables, the resulting local_variable would have a value of '2'. Additionally, if any of the components referenced by the count function evaluate to multiple values, then those values are used in the count calculation. For example, assume that there are two components, one of which resolves to a single value, the other of which resolves to two values. If the count function is used to provide a count of these two components, the function will resolve to a local_variable with the values '3'. + + + + + + + + + + + + + + + The ArithmeticEnumeration simple type defines basic arithmetic operations. Currently add and multiply are defined. + + + + + + + + + + The DateTimeFormatEnumeration simple type defines the different date-time formats that are understood by OVAL. Note that in some cases there are a few different possibilities within a given format. Each of these possibilities is unique though and can be distinguished from each other. The different formats are used to clarify the higher level structure of the date-time string being used. + + + + + The year_month_day value specifies date-time strings that follow the formats: 'yyyymmdd', 'yyyymmddThhmmss', 'yyyy/mm/dd hh:mm:ss', 'yyyy/mm/dd', 'yyyy-mm-dd hh:mm:ss', or 'yyyy-mm-dd' + + + + + The month_day_year value specifies date-time strings that follow the formats: 'mm/dd/yyyy hh:mm:ss', 'mm/dd/yyyy', 'mm-dd-yyyy hh:mm:ss', 'mm-dd-yyyy', 'NameOfMonth, dd yyyy hh:mm:ss' or 'NameOfMonth, dd yyyy', 'AbreviatedNameOfMonth, dd yyyy hh:mm:ss', or 'AbreviatedNameOfMonth, dd yyyy' + + + + + The day_month_year value specifies date-time strings that follow the formats: 'dd/mm/yyyy hh:mm:ss', 'dd/mm/yyyy', 'dd-mm-yyyy hh:mm:ss', or 'dd-mm-yyyy' + + + + + The win_filetime value specifies date-time strings that follow the windows file time format. + + + + + The seconds_since_epoch value specifies date-time values that represent the time in seconds since the UNIX epoch. The Unix epoch is the time 00:00:00 UTC on January 1, 1970. + + + + + + + The FilterActionEnumeration simple type defines the different options for filtering sets of items. + + + + + The exclude value specifies that all items that match the filter shall be excluded from set that the filter is applied to. + + + + + The include value specifies that only items that match the filter shall be included in the set that the filter is applied to. + + + + + + + The SetOperatorEnumeration simple type defines acceptable set operations. Set operations are used to take multiple different sets of objects within OVAL and merge them into a single unique set. The different operators that guide this merge are defined below. For each operator, if only a single object has been supplied, then the resulting set is simply that complete object. + + Below are some tables that outline how different flags are combined with a given set_operator to return a new flag. These tables are needed when computing the flag for collected objects that represent object sets in an OVAL Definition. The top row identifies the flag associated with the first set or object reference. The left column identifies the flag associated with the second set or object reference. The matrix inside the table represent the resulting flag when the given set_operator is applied. (E=error, C=complete, I=incomplete, DNE=does not exist, NC=not collected, NA=not applicable) + + || || + set_operator is || obj 1 flag || + union || || + || E | C | I | DNE | NC | NA || +-----------------||-----------------------------------|| + E || E | E | E | E | E | E || + obj C || E | C | I | C | I | C || + 2 I || E | I | I | I | I | I || + flag DNE || E | C | I | DNE | I | DNE || + NC || E | I | I | I | NC | NC || + NA || E | C | I | DNE | NC | NA || +-----------------||-----------------------------------|| + + + || || + set_operator is || obj 1 flag || + intersection || || + || E | C | I | DNE | NC | NA || +-----------------||-----------------------------------|| + E || E | E | E | DNE | E | E || + obj C || E | C | I | DNE | NC | C || + 2 I || E | I | I | DNE | NC | I || + flag DNE || DNE | DNE | DNE | DNE | DNE | DNE || + NC || E | NC | NC | DNE | NC | NC || + NA || E | C | I | DNE | NC | NA || +-----------------||-----------------------------------|| + + + || || + set_operator is || obj 1 flag || + complement || || + || E | C | I | DNE | NC | NA || +-----------------||-----------------------------------|| + E || E | E | E | DNE | E | E || + obj C || E | C | I | DNE | NC | E || + 2 I || E | E | E | DNE | NC | E || + flag DNE || E | C | I | DNE | NC | E || + NC || E | NC | NC | DNE | NC | E || + NA || E | E | E | E | E | E || +-----------------||-----------------------------------|| + + + + + + + The complement operator is defined in OVAL as a relative complement. The resulting unique set contains everything that belongs to the first declared set that is not part of the second declared set. If A and B are sets (with A being the first declared set), then the relative complement is the set of elements in A, but not in B, with the duplicates removed. + + + + + The intersection of two sets in OVAL results in a unique set that contains everything that belongs to both sets in the collection, but nothing else. If A and B are sets, then the intersection of A and B contains all the elements of A that also belong to B, but no other elements, with the duplicates removed. + + + + + The union of two sets in OVAL results in a unique set that contains everything that belongs to either of the original sets. If A and B are sets, then the union of A and B contains all the elements of A and all elements of B, with the duplicates removed. + + + + + + + + + + + The EntityAttributeGroup is a collection of attributes that are common to all entities. This group defines these attributes and their default values. Individual entities may limit allowed values for these attributes, but all entities will support these attributes. + + + + + + + - a var_ref has been supplied for the entity so no value should be provided + - inconsistent datatype between the variable and an associated var_ref + + + - a var_ref has been supplied for the entity so a var_check should also be provided + + + - a var_check has been supplied for the entity so a var_ref must also be provided + + + - a var_ref has been supplied for the entity so a var_check should also be provided + + + - a var_check has been supplied for the entity so a var_ref must also be provided + + + + - The use of '' for the operation attribute of the entity is not valid given the lack of a declared datatype (hence a default datatype of string). + + + - The use of '' for the operation attribute of the entity is not valid given a datatype of binary. + + + + - The use of '' for the operation attribute of the entity is not valid given a datatype of boolean. + + + + - The use of '' for the operation attribute of the entity is not valid given a datatype of evr_string. + + + + - The use of '' for the operation attribute of the entity is not valid given a datatype of fileset_revision. + + + - The use of '' for the operation attribute of the entity is not valid given a datatype of float. + + + + - The use of '' for the operation attribute of the entity is not valid given a datatype of ios_version. + + + - The use of '' for the operation attribute of the entity is not valid given a datatype of int. + + + + - The use of '' for the operation attribute of the entity is not valid given a datatype of ipv4_address. + + + + - The use of '' for the operation attribute of the entity is not valid given a datatype of ipv6_address. + + + + - The use of '' for the operation attribute of the entity is not valid given a datatype of string. + + + - The use of '' for the operation attribute of the entity is not valid given a datatype of version. + + + - The use of '' for the operation attribute of the entity is not valid given a datatype of record. + + + + + - The use of var_ref is prohibited when the datatype is 'record'. + + + + + - The datatype for the entity is 'int' but the value is not an integer. + + + + + + + + The optional datatype attribute specifies how the given operation should be applied to the data. Since we are dealing with XML everything is technically a string, but often the value is meant to represent some other datatype and this affects the way an operation is performed. For example, with the statement 'is 123 less than 98'. If the data is treated as integers the answer is no, but if the data is treated as strings, then the answer is yes. Specifying a datatype defines how the less than operation should be performed. Another way of thinking of things is that the datatype attribute specifies how the data should be cast before performing the operation (note that the default datatype is 'string'). In the previous example, if the datatype is set to int, then '123' and '98' should be cast as integers. Another example is applying the 'equals' operation to '1.0.0.0' and '1.0'. With datatype 'string' they are not equal, with datatype 'version' they are. Note that there are certain cases where a cast from one datatype to another is not possible. If a cast cannot be made, (trying to cast 'abc' to an integer) then an error should be reported. For example, if the datatype is set to 'integer' and the value is the empty string. There is no way to cast the empty string (or NULL) to an integer, and in cases like this an error should be reported. + + + + + The optional operation attribute determines how the individual entities should be evaluated (the default operation is 'equals'). + + + + + The optional mask attribute is used to identify values that have been hidden for sensitivity concerns. This is used by the result file which uses the system characteristic schema to format the information found on a specific system. If the mask attribute is set to 'true', then the observed value of this field must not be presented in the results file. A system characteristics file that is not held within a results file must not use the mask attribute. It is possible for masking conflicts to occur where one entity has mask set to true and another entity has mask set to false. A conflict will occur when the mask attribute is set differently on an OVAL Object and matching OVAL State or when more than one OVAL Objects identify the same OVAL Item(s). When such a conflict occurs the result is always to mask the entity. + + + + + The optional var_ref attribute refers the value of the element to a variable element. When supplied, the value(s) associated with the OVAL Variable should be used as the value(s) of the element. If there is an error computing the value of the variable, then that error should be passed up to the element referencing it. If the variable being referenced does not have a value (for example, if the variable pertains to the size of a file, but the file does not exist) then one of two results are possible. If the element is part of an object declaration, then the object element referencing it is considered to not exist. If the element is part of a state declaration, then the state element referencing it will evaluate to error. + + + + + The optional var_check attribute specifies how data collection or state evaluation should proceed when an element uses a var_ref attribute, and the associated variable defines more than one value. For example, if an object entity 'filename' with an operation of 'not equal' references a variable that returns five different values, and the var_check attribute has a value of 'all', then an actual file on the system matches only if the actual filename does not equal any of the variable values. As another example, if a state entity 'size' with an operation of 'less than' references a variable that has five different integer values, and the var_check attribute has a value of 'all', then the 'size' state entity evaluates to true only if the corresponding 'size' item entity is less than each of the five integers defined by the variable. If a variable does not have any value value when referenced by an OVAL Object the object should be considered to not exist. If a variable does not have any value when referenced by an OVAL State an error should be reported during OVAL analysis. When an OVAL State uses a var_ref, if both the state entity and a corresponding item entity have multiple values, the var_check is applied to each value of the item entity individually, and all must evaluate to true for the state entity to evaluate to true. In this condition, there is no value of var_check which enables an element-wise comparison, and so there is no way to determine whether two multi-valued entities are truly 'equal' in that sense. If var_ref is present but var_check is not, the element should be processed as if var_check has the value "all". + + + + + + + The EntitySimpleBaseType complex type is an abstract type that defines the default attributes associated with every simple entity. Entities can be found in both OVAL Objects and OVAL States and represent the individual properties associated with items found on a system. An example of a single entity would be the path of a file. Another example would be the version of the file. + + + + + + + + + + + The EntityComplexBaseType complex type is an abstract type that defines the default attributes associated with every complex entity. Entities can be found in both OVAL Objects and OVAL States and represent the individual properties associated with items found on a system. An example of a single entity would be the path of a file. Another example would be the version of the file. + + + + + + + The EntityObjectIPAddressType type is extended by the entities of an individual OVAL Object. This type provides uniformity to each object entity by including the attributes found in the EntitySimpleBaseType. This specific type describes any IPv4/IPv6 address or address prefix. + + + + + + + + + + + + + + + + + + + + The EntityObjectIPAddressStringType type is extended by the entities of an individual OVAL Object. This type provides uniformity to each object entity by including the attributes found in the EntitySimpleBaseType. This specific type describes any IPv4/IPv6 address, address prefix, or its string representation. + + + + + + + + + + + + + + + + + + + + + The EntityObjectAnySimpleType type is extended by the entities of an individual OVAL Object. This type provides uniformity to each object entity by including the attributes found in the EntitySimpleBaseType. This specific type describes any simple data. + + + + + + + + + + + + + The EntityBinaryType type is extended by the entities of an individual OVAL Object. This type provides uniformity to each object entity by including the attributes found in the EntitySimpleBaseType. This specific type describes simple binary data. The empty string is also allowed when using a variable reference with an element. + + + + + + + + + + + + + The EntityBoolType type is extended by the entities of an individual OVAL Object. This type provides uniformity to each object entity by including the attributes found in the EntitySimpleBaseType. This specific type describes simple boolean data. The empty string is also allowed when using a variable reference with an element. + + + + + + + + + + + + + The EntityObjectFloatType type is extended by the entities of an individual OVAL Object. This type provides uniformity to each object entity by including the attributes found in the EntitySimpleBaseType. This specific type describes simple float data. The empty string is also allowed when using a variable reference with an element. + + + + + + + + + + + + + The EntityIntType type is extended by the entities of an individual OVAL Object. This type provides uniformity to each object entity by including the attributes found in the EntitySimpleBaseType. This specific type describes simple integer data. The empty string is also allowed when using a variable reference with an element. + + + + + + + + + + + + + The EntityStringType type is extended by the entities of an individual OVAL Object. This type provides uniformity to each object entity by including the attributes found in the EntitySimpleBaseType. This specific type describes simple string data. + + + + + + + + + + + + + The EntityObjectVersionType type is extended by the entities of an individual OVAL State. This type provides uniformity to each state entity by including the attributes found in the EntityStateSimpleBaseType. This specific type describes simple version data. + + + + + + + + + + + + + The EntityObjectRecordType defines an entity that consists of a number of uniquely named fields. This structure is used for representing a record from a database query and other similar structures where multiple related fields must be represented at once. Note that for all entities of this type, the only allowed datatype is 'record' and the only allowed operation is 'equals'. During analysis of a system characteristics item, each field is analyzed and then the overall result for elements of this type is computed by logically anding the results for each field and then applying the entity_check attribute. + Note the datatype attribute must be set to 'record'. + + Note the operation attribute must be set to 'equals'. + Note the var_ref attribute is not permitted and the var_check attribute does not apply. + Note that when the mask attribute is set to 'true', all child field elements must be masked regardless of the child field's mask attribute value. + + + + + + + + + + + + The EntityObjectFieldType defines an element with simple content that represents a named field in a record that may contain any number of named fields. The EntityObjectFieldType is much like all other entities with one significant difference, the EntityObjectFieldType has a name attribute + The required name attribute specifies a unique name for the field. Field names are lowercase and must be unique within a given parent record element. When analyzing system characteristics an error should be reported for the result of a field that is present in the OVAL State, but not found in the system characteristics Item. + The optional entity_check attribute specifies how to handle multiple record fields with the same name in the OVAL Systems Characteristics file. For example, while collecting group information where one field is the represents the users that are members of the group. It is very likely that there will be multiple fields with a name of 'user' associated with the group. If the OVAL State defines the value of the field with name equal 'user' to equal 'Fred', then the entity_check attribute determines if all values for field entities must be equal to 'Fred', or at least one value must be equal to 'Fred', etc. + Note that when the mask attribute is set to 'true' on a field's parent element the field must be masked regardless of the field's mask attribute value. + + + + + + A string restricted to disallow upper case characters. + + + + + + + + + + + + + + + + The EntityStateSimpleBaseType complex type is an abstract type that extends the EntitySimpleBaseType and is used by some entities within an OVAL State. + The optional entity_check attribute specifies how to handle multiple item entities with the same name in the OVAL Systems Characteristics file. For example, suppose we are dealing with a Group Test and an entity in the state is related to the user. It is very likely that when the information about the group is collected off of the system (and represented in the OVAL System Characteristics file) that there will be multiple users associated with the group (i.e. multiple 'user' item entities associated with the same 'user' state entity). If the OVAL State defines the value of the user entity to equal 'Fred', then the entity_check attribute determines if all values for 'user' item entities must be equal to 'Fred', or at least one value must be equal to 'Fred', etc. Note that with the exception of the 'none_satisfy' check value, the entity_check attribute can only affect the result of the test if the corresponding OVAL Item allows more than one occurrence of the entity (e.g. 'maxOccurs' is some value greater than one). + The entity_check and var_check attributes are considered together when evaluating a single state entity. When a variable identifies more than one value and multiple item entities with the same name exist, for a single state entity, a many-to-many comparison must be conducted. In this situation, there are many values for the state entity that must be compared to many item entities. Each item entity is compared to the state entity. For each item entity, an interim result is calculated by using the var_check attribute to combine the result of comparing each variable value with a single system value. Then these interim results are combined for each system value using the entity_check attribute. + + + + + + + + + + The EntityStateComplexBaseType complex type is an abstract type that extends the EntityComplexBaseType and is used by some entities within an OVAL State. + The optional entity_check attribute specifies how to handle multiple item entities with the same name in the OVAL Systems Characteristics file. For example, suppose we are dealing with a Group Test and an entity in the state is related to the user. It is very likely that when the information about the group is collected off of the system (and represented in the OVAL System Characteristics file) that there will be multiple users associated with the group (i.e. multiple 'user' item entities associated with the same 'user' state entity). If the OVAL State defines the value of the user entity to equal 'Fred', then the entity_check attribute determines if all values for 'user' item entities must be equal to 'Fred', or at least one value must be equal to 'Fred', etc. Note that with the exception of the 'none_satisfy' check value, the entity_check attribute can only affect the result of the test if the corresponding OVAL Item allows more than one occurrence of the entity (e.g. 'maxOccurs' is some value greater than one). + The entity_check and var_check attributes are considered together when evaluating a single state entity. When a variable identifies more than one value and multiple item entities with the same name exist, for a single state entity, a many-to-many comparison must be conducted. In this situation, there are many values for the state entity that must be compared to many item entities. Each item entity is compared to the state entity. For each item entity, an interim result is calculated by using the var_check attribute to combine the result of comparing each variable value with a single system value. Then these interim results are combined for each system value using the entity_check attribute. + + + + + + + + + + The EntityStateIPAddressType type is extended by the entities of an individual OVAL State. This type provides uniformity to each object entity by including the attributes found in the EntityStateSimpleBaseType. This specific type describes any IPv4/IPv6 address or address prefix. + + + + + + + + + + + + + + + + + + + + The EntityStateIPAddressStringType type is extended by the entities of an individual OVAL State. This type provides uniformity to each object entity by including the attributes found in the EntityStateSimpleBaseType. This specific type describes any IPv4/IPv6 address, address prefix, or its string representation. + + + + + + + + + + + + + + + + + + + + + The EntityStateAnySimpleType type is extended by the entities of an individual OVAL State. This type provides uniformity to each state entity by including the attributes found in the EntityStateSimpleBaseType. This specific type describes any simple data. + + + + + + + + + + + + + The EntityStateBinaryType type is extended by the entities of an individual OVAL State. This type provides uniformity to each state entity by including the attributes found in the EntityStateSimpleBaseType. This specific type describes simple binary data. The empty string is also allowed when using a variable reference with an element. + + + + + + + + + + + + + The EntityStateBoolType type is extended by the entities of an individual OVAL State. This type provides uniformity to each state entity by including the attributes found in the EntityStateSimpleBaseType. This specific type describes simple boolean data. The empty string is also allowed when using a variable reference with an element. + + + + + + + + + + + + + The EntityStateFloatType type is extended by the entities of an individual OVAL State. This type provides uniformity to each state entity by including the attributes found in the EntityStateSimpleBaseType. This specific type describes simple float data. The empty string is also allowed when using a variable reference with an element. + + + + + + + + + + + + + The EntityStateIntType type is extended by the entities of an individual OVAL State. This type provides uniformity to each state entity by including the attributes found in the EntityStateSimpleBaseType. This specific type describes simple integer data. The empty string is also allowed when using a variable reference with an element. + + + + + + + + + + + + + The EntityStateEVRStringType type is extended by the entities of an individual OVAL State. This type provides uniformity to each state entity by including the attributes found in the EntityStateSimpleBaseType. This type represents the epoch, version, and release fields as a single version string. It has the form "EPOCH:VERSION-RELEASE". Note that a null epoch (or '(none)' as returned by rpm) is equivalent to '0' and would hence have the form 0:VERSION-RELEASE. Comparisons involving this datatype should follow the algorithm of librpm's rpmvercmp() function. + + + + + + + + + + + + + + The EntityStateVersionType type is extended by the entities of an individual OVAL State. This type provides uniformity to each state entity by including the attributes found in the EntityStateSimpleBaseType. This specific type describes simple version data. + + + + + + + + + + + + + The EntityStateFileSetRevisionType type is extended by the entities of an individual OVAL State. This type provides uniformity to each state entity by including the attributes found in the EntityStateSimpleBaseType. This specific type represents the version string related to filesets in HP-UX. + + + + + + + + + + + + + The EntityStateIOSVersionType type is extended by the entities of an individual OVAL State. This type provides uniformity to each state entity by including the attributes found in the EntityStateSimpleBaseType. This specific type represents the version string related to CISCO IOS. + + + + + + + + + + + + + 'string' is included to allow for regular expressions on IOS version strings. + + + + + + + + + + + The EntityStateStringType type is extended by the entities of an individual OVAL State. This type provides uniformity to each state entity by including the attributes found in the EntityStateSimpleBaseType. This specific type describes simple string data. + + + + + + + + + + + + + The EntityStateRecordType defines an entity that consists of a number of uniquely named fields. This structure is used for representing a record from a database query and other similar structures where multiple related fields must be collected at once. Note that for all entities of this type, the only allowed datatype is 'record' and the only allowed operation is 'equals'. During analysis of a system characteristics item, each field is analyzed and then the overall result for elements of this type is computed by logically anding the results for each field and then applying the entity_check attribute. + Note the datatype attribute must be set to 'record'. + + Note the operation attribute must be set to 'equals'. + Note the var_ref attribute is not permitted and the var_check attribute does not apply. + Note that when the mask attribute is set to 'true', all child field elements must be masked regardless of the child field's mask attribute value. + + + + + + + + + + + + The EntityStateFieldType defines an element with simple content that represents a named field in a record that may contain any number of named fields. The EntityStateFieldType is much like all other entities with one significant difference, the EntityStateFieldType has a name attribute + The required name attribute specifies a unique name for the field. Field names are lowercase and must be unique within a given parent record element. When analyzing system characteristics an error should be reported for the result of a field that is present in the OVAL State, but not found in the system characteristics Item. + The optional entity_check attribute specifies how to handle multiple record fields with the same name in the OVAL Systems Characteristics file. For example, while collecting group information where one field is the represents the users that are members of the group. It is very likely that there will be multiple fields with a name of 'user' associated with the group. If the OVAL State defines the value of the field with name equal 'user' to equal 'Fred', then the entity_check attribute determines if all values for field entities must be equal to 'Fred', or at least one value must be equal to 'Fred', etc. + Note that when the mask attribute is set to 'true' on a field's parent element the field must be masked regardless of the field's mask attribute value. + + + + + + A string restricted to disallow upper case characters. + + + + + + + + + + + + + diff --git a/stix_validator/schema/external/oval_5.10/oval-variables-schema.xsd b/stix_validator/schema/external/oval_5.10/oval-variables-schema.xsd new file mode 100755 index 0000000..52a4588 --- /dev/null +++ b/stix_validator/schema/external/oval_5.10/oval-variables-schema.xsd @@ -0,0 +1,84 @@ + + + + + + + The following is a description of the elements, types, and attributes that compose the core schema for encoding Open Vulnerability and Assessment Language (OVAL) Variables. This schema is provided to give structure to any external variables and their values that an OVAL Definition is expecting. + The OVAL Schema is maintained by The MITRE Corporation and developed by the public OVAL Community. For more information, including how to get involved in the project and how to submit change requests, please visit the OVAL website at http://oval.mitre.org. + + Core Variable + 5.10.1 + 1/27/2012 1:22:32 PM + Copyright (c) 2002-2012, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the OVAL License located at http://oval.mitre.org/oval/about/termsofuse.html. See the OVAL License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the OVAL Schema, this license header must be included. + + + + + + + + + The oval_variables element is the root of an OVAL Variable Document. Its purpose is to bind together the different variables contained in the document. The generator section must be present and provides information about when the variable file was compiled and under what version. The optional Signature element allows an XML Signature as defined by the W3C to be attached to the document. This allows authentication and data integrity to be provided to the user. Enveloped signatures are supported. More information about the official W3C Recommendation regarding XML digital signatures can be found at http://www.w3.org/TR/xmldsig-core/. + + + + + + + + + + + Enforce uniqueness amongst the variable ids found in the variable document. + + + + + + + + + + + + + + + The VariablesType complex type is a container for one or more variable elements. Each variable element holds the value of an external variable used in an OVAL Definition. Please refer to the description of the VariableType for more information about an individual variable. + + + + + + + + Each variable element contains the associated datatype and value which will be substituted into the OVAL Definition that is referencing this specific variable. + + + + + + + + Note that the 'record' datatype is not permitted on variables. + + + + + + + + + + + + diff --git a/stix_validator/schema/external/oval_5.10/xmldsig-core-schema.xsd b/stix_validator/schema/external/oval_5.10/xmldsig-core-schema.xsd new file mode 100755 index 0000000..9f11f60 --- /dev/null +++ b/stix_validator/schema/external/oval_5.10/xmldsig-core-schema.xsd @@ -0,0 +1,309 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/stix_validator/schema/incident.xsd b/stix_validator/schema/incident.xsd new file mode 100755 index 0000000..63bc6d6 --- /dev/null +++ b/stix_validator/schema/incident.xsd @@ -0,0 +1,786 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Incident + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) - Incident - Schematic implementation for the Incident construct within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + + + This field characterizes a single cyber threat Incident. + + + + + The IncidentType characterizes a single cyber threat Incident. + + + + + + + The Title field provides a simple title for this Incident. + + + + + The Time filed specifies relevant time values associated with this Incident. + + + + + The Description field provides a description of this Incident. + + + + + The Categories field provides a set of categories for this incident. + + + + + The Reporter field details information about the reporting source of this Incident. + + + + + The Responder field is optional and details information about the assigned responder for this Incident. + + + + + The Coordinator field is optional and details information about the assigned coordinator for this Incident. + + + + + + The Victim field is optional and details information about a victim of this Incident. + + This field is implemented through the xsi:type extension mechanism. The default type is CIQIdentity3.0InstanceType in the http://stix.mitre.org/extensions/Identity#CIQIdentity3.0-1 namespace. This type is defined in the extensions/identity/ciq_identity.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/identity/ciq_identity/1.0/ciq_identity.xsd. + + Those who wish to express a simple name may also do so by not specifying an xsi:type and using the Name field. + + + + + + The Affected_Assets field is optional and characterizes the particular assets affected during the Incident. + + + + + The Impact_Assessment field specifies a summary assessment of impact for this cyber threat Incident. + + + + + + Status describes the current status (sometimes called "state" or "disposition") of the incident. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is IncidentStatusVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + The Related_Indicators field identifies or characterizes one or more cyber threat Indicators related to this cyber threat Incident. + + + + + The Related_Observables field identifies or characterizes one or more cyber observables related to this cyber threat incident. + + + + + The Leveraged_TTPs field specifies TTPs asserted to be related to this cyber threat Incident. + + + + + The Attributed_Threat_Actors field identifies ThreatActors asserted to be attributed for this Incident. + + + + + + The Intended_Effect field specifies the suspected intended effect of this incident. + + It is implemented through the StatementType, which allows for the expression of a statement in a vocabulary (Value), a description of the statement (Description), a confidence in the statement (Confidence), and the source of the statement (Source). The default vocabulary type for the Value is IntendedEffectVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + Specifies knowledge of whether the Incident involved a compromise of security properties. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is SecurityCompromiseVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Discovery_Method field identifies how the incident was discovered. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is DiscoveryMethodVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + The Related_Incidents field identifies or characterizes one or more other Incidents related to this cyber threat Incident. + + + + + The COA_Requested field specifies and characterizes a requested CourseOfAction for this Incident as specified by the Producer for the Consumer of the Incident Report + + + + + The COA_Taken field specifies and characterizes a CourseOfAction taken for this Incident. + + + + + The Confidence field characterizes the level of confidence held in the characterization of this Incident. + + + + + The Contact field identifies and characterizes organizations or personnel involved in this Incident. + + + + + The History field provides a log of events or actions taken during the handling of the Incident. + + + + + The Handling field specifies the appropriate data handling markings for the elements of this Incident. The valid marking scope is the nearest IncidentBaseType ancestor of this Handling element and all its descendants. + + + + + + Specifies the relevant STIX-Incident schema version for this content. + + + + + Specifies a URL referencing the location for the Incident specification. + + + + + + + + + An enumeration of all versions of the Incident type valid in the current release of STIX. + + + + + + + + + + + The security property that was affected by the incident. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is LossPropertyVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + The Description_Of_Effect field is optional and provides a brief prose description of how the security property was affected. + + + + + + The Type_Of_Availability_Loss field is optional and characterizes in what manner the availability of this asset was affected (e.g. Destruction, Deletion, Interruption). + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is AvailabilityLossTypeVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Duration_Of_Availability_Loss field is optional and specifies the approximate length of time availability was affected (e.g. Permanent, Seconds, Minutes, Hours, Days). + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is LossDurationVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + This field specifies whether non-public data was compromised or exposed. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is SecurityCompromiseVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + + + + The Type field is optional and specifies the type of the asset impacted by the incident (a security attribute was negatively affected). + + + + + The Description field is optional and provides a brief prose description of the asset. + + + + + The Business_Function_Or_Role field is optional and provides a brief description of the asset's role, mission, and importance within the organization. + + + + + + The Ownership_Class field is optional and gives a high-level characterization of who owns (or controls) this asset (e.g. Internally-owned, Employee-owned, Partner-owned, Customer-owned). + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is OwnershipClassVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Management_Class field is optional and gives a high-level characterization of who is responsible for the day-to-day management and administration of this asset (e.g. Managed Internally, Managed by External Party, Co-managed). + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is ManagementClassVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + The Location_Class field is optional and gives a high-level characterization of where this asset is physically located (e.g. Internal location, External location, Co-located, Mobile). + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is LocationClassVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Location field specifies the physical location of the affected asset. + + This field is implemented through the xsi:type extension mechanism. The default type is CIQAddressInstanceType in the http://stix.mitre.org/extensions/Identity#CIQAddress-1 namespace. This type is defined in the extensions/address/ciq_address_3.0.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/address/ciq_address/1.0/ciq_address_3.0.xsd. + + Those who wish to express a simple name may also do so by not specifying an xsi:type and using the Name field. + + + + + + The Nature_Of_Security_Effect field is optional and characterizes how the security properties of the Asset were affected. + + + + + The Structured_Description field is optional and provides a structured description of the asset. + + + + + + + + The ImpactAssessmentType specifies a summary assessment of impact for this cyber threat Incident. + + + + + The Direct_Impact_Summary field is optional and characterizes (at a high level) losses directly resulting from the ThreatActor's actions against organizational assets within the Incident. + + + + + The Indirect_Impact_Summary field is optional and characterizes (at a high level) losses from other stakeholder reactions to the Incident. + + + + + The Total_Loss_Estimation field is optional and specifies the total estimated financial loss for the Incident. + + + + + + The Impact_Qualification field is optional and summarizes the subjective level of impact of the Incident. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is ImpactQualificationVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + The Effects field captures a list of effects of this incident from a controlled vocabulary. + + + + + The External_Impact_Assessment_Model field is optional and characterizes impact assessment details utilizing impact assessment characterization models defined external to STIX. It is defined utilizing an abstract type enabling the definition through extension of incident impact assessment models external to STIX. + + + + + + + The ExternalImpactAssessmentModelType is an abstract type enabling the definition through extension of incident impact assessment models external to STIX. + + + + Specifies the name of the externally defined impact assessment model. + + + + + Specifies a URL reference for the externally defined impact assessment model. + + + + + + + + + The Time field specifies the relative time criteria for this taken CourseOfAction. + + + + + The Contributors field specifies contributing actors for the CourseOfAction taken. + + + + + + The Course_Of_Action field specifies the actual CourseOfAction taken. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is CourseOfActionType in the http://stix.mitre.org/CourseOfAction-1 namespace. This type is defined in the course_of_action.xsd file or at the URL http://stix.mitre.org/XMLSchema/course_of_action/1.0/course_of_action.xsd. + + + + + + + + The JournalEntryType is optional and provides journal notes for information discovered during the handling of the Incident. + + + + + + Specifies the author of the JournalEntry note. + + + + + Specifies the date and time that the JournalEntry note was written. + + + + + + + + + + + Specifies a suggested level of priority to be applied to this requested COA. + + + + + + + + + + + + + + + The Start field specifies the time at which the CourseOfAction was begun. + + + + + The End field specifies the time at which the CourseOfAction was completed. + + + + + + + + Specifies the estimated financial loss for the Incident. + + + + + Specifies the ISO 4217 currency code if other than USD + + + + + + + + The Initial_Reported_Total_Loss_Estimation field is optional and specifies the initially reported level of total estimated financial loss for the Incident. + + + + + The Actual_Total_Loss_Estimation field is optional and specifies the actual level of total estimated financial loss for the Incident. + + + + + + + + + + The Loss_Of_Competitive_Advantage field is optional and characterizes (at a high level) the level of impact based on loss of competitive advantage that occured in the Incident including loss/damage/exposure of IP, corporate wisdom, ability to compete, key personnel, etc. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is SecurityCompromiseVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Brand_And_Market_Damage field is optional and characterizes (at a high level) the level of impact based on brand or market damage that occured in the Incident including lost customers or partners, decrease in market value or share, advertising, rebranding, etc. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is SecurityCompromiseVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Increased_Operating_Costs field is optional and characterizes (at a high level) the level of impact based on increased operating costs that occured in the Incident including cost of additional audits, new hires or training, mandatory action, higher insurance, etc. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is SecurityCompromiseVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Legal_And_Regulatory_Costs field is optional and characterizes (at a high level) the level of impact based on legal and regulatory costs that occured in the Incident including legal fees, lawsuits, customer damages, contract violations, etc. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is SecurityCompromiseVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + + + + + The Asset_Losses field is optional and characterizes (at a high level) the level of asset-related losses that occured in the Incident, including lost or damaged assets, stolen funds, cash outlays, etc. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is ImpactRatingVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Business-Mission_Disruption field is optional and characterizes (at a high level) the level of business or mission disruption impact that occured in the Incident including unproductive man-hours, lost revenue from system downtime, etc. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is ImpactRatingVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Response_And_Recovery_Costs field is optional and characterizes (at a high level) the level of response and recovery related costs that occured in the Incident including cost of response, investigation, remediation, restoration, etc. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is ImpactRatingVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + + + + The Property_Affected field is optional and characterizes how a particular security property of the Asset was affected. + + + + + + + + + + + This field specifies the number of assets of this type affected. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is AssetTypeVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + + + + + The Action_Entry field is optional and provides a record of actions taken during the handling of the Incident. + + + + + The Journal_Entry field is optional and provides journal notes for information discovered during the handling of the Incident. + + + + + + + + + The History_Item field provides a log entry of an event or action taken during the handling of the Incident. + + + + + + + + + + + The Related_Incident field identifies or characterizes another Incident related to this Incident. + + + + + + + + + + + + + The Leveraged_TTP field specifies a single TTP asserted to be related to this cyber threat Incident. + + + + + + + + + + + + + The Related_Observable field identifies or characterizes a cyber threat observable related to this Incident. + + + + + + + + + + + + + The Related_Indicator field identifies or characterizes a cyber threat Indicator related to this Incident. + + + + + + + + + The AttributedThreatActorsType specifies a Threat Actor asserted to be attributed for this Incident. + + + + + + + The Threat_Actor field specifies details of a Threat Actor asserted to be attributed for this Incident. + + + + + + + + + + + The Affected_Asset field is optional and characterizes a particular asset affected during the Incident. + + + + + + + + + The First_Malicious_Action field specifies the time that the first malicious action related to this Incident occured. + + + + + The Initial_Compromise field specifies the time that the initial compromise occured for this Incident. + + + + + The First_Data_Exfiltration field specifies the first time at which non-public data was taken from the victim environment + + + + + The Incident_Discovery field specifies the first time at which the organization learned the incident had occurred. + + + + + The Incident_Opened field specifies the time at which the Incident was officially opened. + + + + + The Containment_Achieved field specifies the first time at which the incident is contained (e.g., the “bleeding is stopped”). + + + + + The Restoration_Achieved field specifies the first time at which the incident's assets are restored (e.g., fully functional)”. + + + + + The Incident_Reported field specifies the time at which the Incident was reported. + + + + + The Incident_Closed field specifies the time at which the Incident was officially closed. + + + + + + + Represents a list of incident categories that an incident is tagged with. + + + + + + Represents a single category that this incident is tagged with. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is IncidentCategoryVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + + Represents a list of incident effects that an incident is tagged with. + + + + + + Represents a single effect that this incident is tagged with. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is IncidentEffectVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + diff --git a/stix_validator/schema/indicator.xsd b/stix_validator/schema/indicator.xsd new file mode 100755 index 0000000..1254b1a --- /dev/null +++ b/stix_validator/schema/indicator.xsd @@ -0,0 +1,309 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Indicator + 2.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) - Indicator - Schematic implementation for the Indicator construct within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + + + The IndicatorType characterizes a cyber threat indicator made up of a pattern identifying certain observable conditions as well as contextual information about the patterns meaning, how and when it should be acted on, etc. + + + + + + + The Title field provides a simple title for this Indicator. + + + + + + Specifies the type for this Indicator. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is IndicatorTypeVocabularyType in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + Specifies an alternative identifier (or alias) for the cyber threat Indicator. + + + + + Specifies a description for this Indicator. + + + + + Specifies the time window for which this Indicator is valid. + + + + + Content creators should either create a "simple indicator" containing one observable, or a "composite indicator" containing multiple indicators. + + + + Specifies a relevant cyber observable for this Indicator. + + + + + Specifies a multipartite composite Indicator. + + + + + + Specifies the relevant TTP indicated by this Indicator. + + + + + Specifies relevant kill chain phases indicated by this Indicator. + + + + + The TestMechanisms field specifies Test Mechanisms effective at identifying the cyber Observables specified in this cyber threat Indicator. + + + + + Specifies the likely potential impact within the relevant context if this Indicator were to occur. This is typically local to an Indicator consumer and not typically shared. This field includes a Description of the likely potential impact within the relevant context if this Indicator were to occur and a Confidence held in the accuracy of this assertion. NOTE: This structure potentially still needs to be fleshed out more for structured characterization of impact. + + + + + The Suggested_COAs field specifies suggested Courses of Action for this cyber threat Indicator. + + + + + Specifies the relevant handling guidance for this Indicator. The valid marking scope is the nearest IndicatorBaseType ancestor of this Handling element and all its descendants. + + + + + Specifies a level of confidence held in the accuracy of this Indicator. + + + + + Characterizes a set of sighting reports for this Indicator. + + + + + The Related_Indicators field is optional and enables content producers to express a relationship between the enclosing indicator (i.e., the subject of the relationship) and a disparate indicator (i.e., the object side of the relationship). + + + + + The Producer field details the source of this entry. + + + + + + Specifies the relevant STIX-Indicator schema version for this content. + + + + + The negate field applies when using an Indicator as a pattern and specifies the absence of the pattern. + + + + + + + + An enumeration of all versions of the Indicator type valid in the current release of STIX. + + + + + + + + + A basic representation of a temporal window when the thing (e.g., indicator) is valid. + + + + + If not present, then client should assume infinity (i.e., temporal window is only bounded by the end-time). + + + + + If not present, then client should assume infinity (i.e., temporal window is only bounded by the start-time). + + + + + + + + + + + Type for allowing content creators to create composite indicator expressions using basic boolean logic. + + + + + The indicator field specifies one cyber threat indicator asserting a relationship between a cyber observable and a TTP. + + + + + + Specifies the logical composition operator for this composite cyber threat Indicator. + + + + + + OperatorTypeEnum is an enumeration of valid operators. + + + + + + + + + + + The TestMechanismType specifies a non-standard Test Mechanism effective at identifying the cyber Observables specified in this cyber threat Indicator. + + This type is defined as abstract and is intended to be extended to enable the expression of any structured or unstructured test mechanism. STIX provides five default options, Generic, OpenIOC, OVAL, Snort, and YARA. Additionally, those who wish to use another format may do so by using either the existing Generic test mechanism and putting the mechanism specification in the CDATA block or by defining a new extension to this type. The information for the STIX-provided extensions is: + + 1. Generic: The Generic test mechanism allows for the specification of any generic test mechanism through the use of a raw CDATA section. The type is named GenericTestMechanismType and is in the http://stix.mitre.org/extensions/TestMechanism#Generic-1 namespace. The extension is defined in the file extensions/test_mechanism/generic.xsd or at the URL http://stix.mitre.org/XMLSchema/extensions/test_mechanism/generic/1.0/generic.xsd. + + 2. OpenIOC: The OpenIOC test mechanism allows for the specification of an OpenIOC test by importing the OpenIOC schema. The type is named IOCTestMechanismType and is in the http://stix.mitre.org/extensions/TestMechanism#OpenIOC-1 namespace. The extension is defined in the file extensions/test_mechanism/openioc-1.0.xsd or at the URL http://stix.mitre.org/XMLSchema/extensions/test_mechanism/openioc-1.0/1.0/openioc-1.0.xsd. + + 3. OVAL: The OVAL test mechanism allows for the specification of an OVAL definition through importing the OVAL schemas. The type is named OVALTestMechanismType and is in the http://stix.mitre.org/extensions/TestMechanism#OVAL-1 namespace. The extension is defined in the file extensions/test_mechanism/oval-5.10.1.xsd or at the URL http://stix.mitre.org/XMLSchema/extensions/test_mechanism/oval-5.10.1/1.0/oval-5.10.1.xsd. + + 4. Snort: The Snort test mechanism allows for the specification of a snort signature through the use of a raw CDATA section. The type is named SnortTestMechanismType and is in the http://stix.mitre.org/extensions/TestMechanism#Snort-1 namespace. The extension is defined in the file extensions/test_mechanism/snort.xsd or at the URL http://stix.mitre.org/XMLSchema/extensions/test_mechanism/snort/1.0/snort.xsd. + + 5. YARA: The YARA test mechanism allows for the specification of a YARA test through the use of a raw CDATA section. The type is named YaraTestMechanismType and is in the http://stix.mitre.org/extensions/TestMechanism#YARA-1 namespace. The extension is defined in the file extensions/test_mechanism/yara.xsd or at the URL http://stix.mitre.org/XMLSchema/extensions/test_mechanism/yara/1.0/yara.xsd. + + + + + + The Efficacy field provides an assertion of likely effectiveness of this TestMechanism to detect the targeted cyber Observables. The field includes a description of the asserted efficacy of this TestMechanism and a confidence held in the asserted efficacy of this TestMechanism to detect the targeted cyber Observables. + + + + + The Producer field details the source of this entry. + + + + + + Specifies a unique ID for this Test Mechanism. + + + + + Specifies a reference to the ID of a Test Mechanism specified elsewhere. + + + + + + + + + This field characterizes a single sighting report for this Indicator. + + + + + + The total number of times this Indicator was reported as sighted. + + + + + + Describes a single sighting of an indicator. + + + + + This field provides a name or description of the sighting source. + + + + + This field provides a formal reference to the sighting source. + + + + + This field provides a confidence assertion in the accuracy of this sighting. + + + + + + This field provides the date and time of the Indicator sighting. + + + + + + + + + + The Related_Indicator field is optional and enables content producers to express a relationship between the enclosing indicator (i.e., the subject of the relationship) and a disparate indicator (i.e., the object side of the relationship). + + + + + + + + + + + + + The Suggested_COA field specifies a suggested Course of Action for this cyber threat Indicator. + + + + + + + + + + + The TestMechanism field specifies a non-standard Test Mechanism effective at identifying the cyber Observables specified in this cyber threat Indicator. This field is defined as of type TestMechanismType which is an abstract type enabling the extension and inclusion of various formats of Test Mechanism specifications. + + + + + diff --git a/stix_validator/schema/stix_common.xsd b/stix_validator/schema/stix_common.xsd new file mode 100755 index 0000000..3c61a0d --- /dev/null +++ b/stix_validator/schema/stix_common.xsd @@ -0,0 +1,762 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Common + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) - Common - Schematic implementation for the common types of a structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + The InformationSourceType details the source of a given data entry. + + + + + + The Identity field is optional and specifies the identity of the information source. + + This field is implemented through the xsi:type extension mechanism. The default type is CIQIdentity3.0InstanceType in the http://stix.mitre.org/extensions/Identity#CIQIdentity3.0-1 namespace. This type is defined in the extensions/identity/ciq_identity.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/identity/ciq_identity/1.0/ciq_identity.xsd. + + Those who wish to express a simple name may also do so by not specifying an xsi:type and using the Name field. + + + + + + The Contributors field is optional and enables description of the individual contributors involved in this instance. + + + + + The Time element is optional and enables description of various time-related attributes for this instance. + + + + + The Tools element is optional and enables description of the tools utilized for this instance. + + + + + The References field is optional and enables specification of references to information source material for this instance. + + + + + + + + The ConfidenceType specifies a level of Confidence held in some assertion. + + + + + + Specifies the level of confidence held in this direct assertion. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is HighMediumLowVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + The Description field provides a description of the confidence value and how it was derived. + + + + + + The Source field specifies the source of this confidence assertion. An optional vocabulary name and reference allows the expression of the source name in some given vocabulary context. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. No default vocabulary type has been defined for STIX 1.0. Users may either define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a free string field. + + + + + + The Confidence_Assertion_Chain field specifies a set of related confidence levels in this assertion along with who made them, when they were made and how they were made. + + + + + + Specifies the time of this Confidence assertion. + + + + + + + + + The Date_Time field specifies the date and time at which the activity occured. + + + + + The Description field provides a description of the activity. + + + + + + + + + + This field specifies a single kill chain definition for reference within specific TTP entries, Indicators and elsewhere. + + + + + + + The KillChainType characterizes a specific Kill Chain definition for reference within specific TTP entries, Indicators and elsewhere. + + + + + This field specifies the name of an individual phase within this kill chain definition. + + + + + + A globally unique identifier for this kill chain definition. + + + + + A descriptive name for this kill chain definition. + + + + + The organization or individual responsible for this kill chain definition. + + + + + A resource reference for this kill chain definition. + + + + + The number of phases in this kill chain definition. + + + + + + The KillChainPhaseType characterizes an individual phase within a kill chain definition. + + + + This field specifies the ID for the relevant kill chain phase. + + + + + This field specifies the descriptive name of the relevant kill chain phase. + + + + + This field specifies the ordinality (e.g. 1, 2 or 3) of this phase within this kill chain definition. + + + + + + + + + The Kill_Chain_Phase field specifies a single Kill Chain phase associated with this item. + + + + + + + + + + This field specifies the ID for the relevant defined kill chain. + + + + + This field specifies the descriptive name of the relevant kill chain. + + + + + + + + + + The IdentityType is used to express identity information for both individuals and organizations. + + This type is extended through the xsi:type mechanism. The default type is CIQIdentity3.0InstanceType in the http://stix.mitre.org/extensions/Identity#CIQIdentity3.0-1 namespace. This type is defined in the extensions/identity/ciq_identity_3.0.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/identity/ciq_identity_3.0/1.0/ciq_identity_3.0.xsd. + + Those who wish to express a simple name may also do so by not specifying an xsi:type and using the Name field of this type. + + + + + + The Name field allows for expression of an identity through a simple name. + + + + + The Related_Identities field identifies other entity Identities related to this entity Identity. + + + + + + Specifies a unique ID for this Identity. + + + + + Specifies a reference to a unique ID defined elsewhere. + + + + + + + Allows the expression of a list of relationships between STIX components. It's extended throughout STIX and should not be used directly. + + + + Indicates how multiple related items should be interpreted in this relationship. If "inclusive" is specified, then a single conceptual relationship is being defined between the subject and the collection of objects indicated by the related items (i.e. the relationship is not necessarily relevant for any one particular object being referenced, but for the aggregated collection of objects referenced). If "exclusive" is specified, then multiple relationships are being defined between the specific subject and each object individually. + + + + + + ScopeEnum is an enumeration of potential assertions on how a group of relationships should be treated. + + + + + A single relationship is being defined between the subject and the collection of objects indicated by the related items. + + + + + Multiple relationships are being defined between the specific subject and each object individually. + + + + + + + Allows the expression of relationships between STIX components. It is extended by each component relationship type to add the component itself. + + + + + The confidence field specifies the level of confidence in the assertion of the relationship between the two components. + + + + + The Information_Source field specifies the source of the information about the relationship between the two components. + + + + + + The relationship field characterizes the type of the relationship between the two components. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. No default vocabulary type has been defined for STIX 1.0. Users may either define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a free string field. + + + + + + + + Identifies or characterizes a relationship to a campaign. + + + + + + + + A reference to or representation of the related campaign. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is CampaignType in the http://stix.mitre.org/Campaign-1 namespace. This type is defined in the campaign.xsd file or at the URL http://stix.mitre.org/XMLSchema/campaign/1.0/campaign.xsd. + + + + + + + + + + Identifies or characterizes a relationship to a course of action. + + + + + + + + A reference or representation of the related course of action. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is CourseOfActionType in the http://stix.mitre.org/CourseOfAction-1 namespace. This type is defined in the course_of_action.xsd file or at the URL http://stix.mitre.org/XMLSchema/course_of_action/1.0/course_of_action.xsd. + + + + + + + + + + Identifies or characterizes a relationship to an exploit target. + + + + + + + + A reference to or representation of the related exploit target. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is ExploitTargetType in the http://stix.mitre.org/ExploitTarget-1 namespace. This type is defined in the exploit_target.xsd file or at the URL http://stix.mitre.org/XMLSchema/exploit_target/1.0/exploit_target.xsd. + + + + + + + + + + Identifies or characterizes a relationship to an incident. + + + + + + + + A reference to or representation of the related incident. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is IncidentType in the http://stix.mitre.org/Incident-1 namespace. This type is defined in the incident.xsd file or at the URL http://stix.mitre.org/XMLSchema/incident/1.0/incident.xsd. + + + + + + + + + + Identifies or characterizes a relationship to an indicator. + + + + + + + + A reference to or representation of the related indicator. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is IndicatorType in the http://stix.mitre.org/Indicator-2 namespace. This type is defined in the indicator.xsd file or at the URL http://stix.mitre.org/XMLSchema/indicator/2.0/indicator.xsd. + + + + + + + + + + Identifies or characterizes a relationship to a cyber observable. + + + + + + + A reference to or representation of the related cyber observable. + + + + + + + + + Identifies or characterizes a relationship to a threat actor. + + + + + + + + A reference or representation of the related threat actor. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is ThreatActorType in the http://stix.mitre.org/ThreatActor-1 namespace. This type is defined in the threat_actor.xsd file or at the URL http://stix.mitre.org/XMLSchema/threat_actor/1.0/threat_actor.xsd. + + + + + + + + + + Identifies or characterizes a relationship to an TTP. + + + + + + + + A reference to or representation of the related TTP. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is TTPType in the http://stix.mitre.org/TTP-1 namespace. This type is defined in the ttp.xsd file or at the URL http://stix.mitre.org/XMLSchema/ttp/1.0/ttp.xsd. + + + + + + + + + + Identifies or characterizes a relationship to an Identity. + + + + + + + + A reference to or representation of the related Identity. + + This field is implemented through the xsi:type extension mechanism. The default type is CIQIdentity3.0InstanceType in the http://stix.mitre.org/extensions/Identity#CIQIdentity3.0-1 namespace. This type is defined in the extensions/identity/ciq_identity_3.0.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/identity/ciq_identity_3.0/1.0/ciq_identity_3.0.xsd. + + + + + + + + + + + + + + This type represents the STIX Indicator component. It is extended using the XML Schema Extension feature by the STIX Indicator type itself. Users of this type who wish to express a full indicator using STIX must do so using the xsi:type extension feature. The STIX-defined Indicator type is IndicatorType in the http://stix.mitre.org/Indicator-1 namespace. This type is defined in the indicator.xsd file or at the URL http://stix.mitre.org/XMLSchema/indicator/1.2/indicator.xsd. + + Alternatively, uses that require simply specifying an idref as a reference to an indicator defined elsewhere can do so without specifying an xsi:type. + + + + + Specifies a unique ID for this Indicator. + + + + + Specifies a reference to the ID of an Indicator specified elsewhere. + + + + + + + This type represents the STIX Incident component. It is extended using the XML Schema Extension feature by the STIX Incident type itself. Users of this type who wish to express a full incident using STIX must do so using the xsi:type extension feature. The STIX-defined Incident type is IncidentType in the http://stix.mitre.org/Incident-1 namespace. This type is defined in the incident.xsd file or at the URL http://stix.mitre.org/XMLSchema/incident/1.0/incident.xsd. + + Alternatively, uses that require simply specifying an idref as a reference to an incident defined elsewhere can do so without specifying an xsi:type. + + + + + Specifies a globally unique identifier for this cyber threat Incident. + + + + + Specifies a globally unique identifier for a cyber threat Incident specified elsewhere. + + + + + + + This type represents the STIX TTP component. It is extended using the XML Schema Extension feature by the STIX TTP type itself. Users of this type who wish to express a full TTP using STIX must do so using the xsi:type extension feature. The STIX-defined TTP type is TTPType in the http://stix.mitre.org/TTP-1 namespace. This type is defined in the ttp.xsd file or at the URL http://stix.mitre.org/XMLSchema/ttp/1.0/ttp.xsd. + + Alternatively, uses that require simply specifying an idref as a reference to a TTP defined elsewhere can do so without specifying an xsi:type. + + + + + Specifies a globally unique identifier for this TTP item. + + + + + Specifies a globally unique identifier of a TTP item specified elsewhere. + + + + + + + This type represents the STIX Exploit Target component. It is extended using the XML Schema Extension feature by the STIX Exploit Target type itself. Users of this type who wish to express a full exploit target using STIX must do so using the xsi:type extension feature. The STIX-defined Exploit Target type is ExploitTargetType in the http://stix.mitre.org/ExploitTarget-1 namespace. This type is defined in the exploit_target.xsd file or at the URL http://stix.mitre.org/XMLSchema/exploit_target/1.0/exploit_target.xsd. + + Alternatively, uses that require simply specifying an idref as a reference to an exploit target defined elsewhere can do so without specifying an xsi:type. + + + + + Specifies a globally unique identifier for this ExploitTarget. + + + + + Specifies a globally unique identifier of an ExploitTarget specified elsewhere. + + + + + + + This type represents the STIX Course of Action component. It is extended using the XML Schema Extension feature by the STIX Course of Action type itself. Users of this type who wish to express a full course of action using STIX must do so using the xsi:type extension feature. The STIX-defined Course of Action type is CourseOfActionType in the http://stix.mitre.org/CourseOfAction-1 namespace. This type is defined in the course_of_action.xsd file or at the URL http://stix.mitre.org/XMLSchema/course_of_action/1.0/course_of_action.xsd. + + Alternatively, uses that require simply specifying an idref as a reference to a course of action defined elsewhere can do so without specifying an xsi:type. + + + + + Specifies a globally unique identifier for this COA. + + + + + Specifies a globally unique identifier of a COA specified elsewhere. + + + + + + + This type represents the STIX Campaign component. It is extended using the XML Schema Extension feature by the STIX Campaign type itself. Users of this type who wish to express a full campaign using STIX must do so using the xsi:type extension feature. The STIX-defined Campaign type is CampaignType in the http://stix.mitre.org/Campaign-1 namespace. This type is defined in the campaign.xsd file or at the URL http://stix.mitre.org/XMLSchema/campaign/1.0/campaign.xsd. + + Alternatively, uses that require simply specifying an idref as a reference to a campaign defined elsewhere can do so without specifying an xsi:type. + + + + + Specifies a globally unique identifier for this cyber threat Campaign. + + + + + Specifies a globally unique identifier for a cyber threat Campaign specified elsewhere. + + + + + + + This type represents the STIX Threat Actor component. It is extended using the XML Schema Extension feature by the STIX Threat Actor type itself. Users of this type who wish to express a full threat actor using STIX must do so using the xsi:type extension feature. The STIX-defined Threat Actor type is ThreatActorType in the http://stix.mitre.org/ThreatActor-1 namespace. This type is defined in the threat_actor.xsd file or at the URL http://stix.mitre.org/XMLSchema/threat_actor/1.0/threat_actor.xsd. + + Alternatively, uses that require simply specifying an idref as a reference to a threat actor defined elsewhere can do so without specifying an xsi:type. + + + + + Specifies a globally unique identifier for this ThreatActor. + + + + + Specifies a globally unique identifier of a ThreatActor specified elsewhere. + + + + + + + + + + The Exploit_Target field characterizes a potential vulnerability, weakness or configuration target for exploitation. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is ExploitTargetType in the http://stix.mitre.org/ExploitTarget-1 namespace. This type is defined in the exploit_target.xsd file or at the URL http://stix.mitre.org/XMLSchema/exploit_target/1.0/exploit_target.xsd. + + + + + + + + + The AddressAbstractType is used to express geographic address information. + + This type is intended to be extended through the xsi:type mechanism. The default type is CIQAddress3.0InstanceType in the http://stix.mitre.org/extensions/Address#CIQAddress3.0-1 namespace. This type is defined in the extensions/identity/ciq_address_3.0.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/address/ciq_address_3.0/1.0/ciq_address_3.0.xsd. + + + + + + + + + This field contains information describing the identity, resources and timing of involvement for a single contributor. + + This field is implemented through the xsi:type extension mechanism. The default type is CIQIdentity3.0InstanceType in the http://stix.mitre.org/extensions/Identity#CIQIdentity3.0-1 namespace. This type is defined in the extensions/identity/ciq_identity.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/identity/ciq_identity/1.0/ciq_identity.xsd. + + Those who wish to express a simple name may also do so by not specifying an xsi:type and using the Name field. + + + + + + + + + + The Reference field is optional and enables specification of a reference to an information source material. + + + + + + + + + The Related_Identity field identifies a single other entity Identity related to this entity Identity. + + + + + + + + + The Confidence_Assertion field specifies a related confidence level in this assertion along with who made it, when it was made and how it was made. + + + + + + + + StatementType allows the expression of a statement with an associated value, description, source, confidence, and timestamp. + + + + + + + Specifies a value characterizing the statement within some vocabulary. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary may be provided by the field using this construct. If that's the case, the schema annotations on that element will describe which vocabulary to use. If not, the default vocabulary is HighMediumLowVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + Specifies a prose description of the statement. + + + + + + The Source field captures the source of this statement. An optional vocabulary name and reference allows the expression of the source name in some given vocabulary context. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. No default vocabulary type has been defined for STIX 1.0. Users may either define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a free string field. + + + + + + The Confidence field characterizes the level of confidence held in the statement. + + + + + + Specifies the time this statement was asserted. + + + + + + The StructuredTextType is a type representing a generalized structure for capturing structured or unstructured textual information such as descriptions of things. It mirrors a similar type in CybOX 2.0 + + + + + + Used to indicate a particular structuring format (e.g., HTML5) used within an instance of StructuredTextType. Note that if the markup tags used by this format would be interpreted as XML information (such as the bracket-based tags of HTML) the text area should be enclosed in a CDATA section to prevent the markup from interferring with XML validation of the CybOX document. If this attribute is absent, the implication is that no markup is being used. + + + + + + + + + This type is used to represent data in an XML CDATA block. Data in a CDATA block may either be represented as-is or, in cases where it may contain characters that are not valid in CDATA, it may be encoded in Base64 per RFC4648. Data encoded in Base64 must be denoted as such using the encoded attribute. + + + + + + + If true, specifies that the content encoded in the element is encoded using Base64 per RFC4648. + + + + + + + + The ControlledVocabularyStringType is used as the basis for defining controlled vocabularies. + + + + + + The vocab_name field specifies the name of the controlled vocabulary. + + + + + The vocab_reference field specifies the URI to the location of where the controlled vocabulary is defined, e.g., in an externally located XML schema file. + + + + + + diff --git a/stix_validator/schema/stix_core.xsd b/stix_validator/schema/stix_core.xsd new file mode 100755 index 0000000..46ed679 --- /dev/null +++ b/stix_validator/schema/stix_core.xsd @@ -0,0 +1,217 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) - Schematic implementation for a structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + + The STIX_Package field contains a bundle of information characterized in the Structured Threat Information eXpression (STIX) language. + + + + + STIXType defines a bundle of information characterized in the Structured Threat Information eXpression (STIX) language. + + + + + The STIX_Header field provides information characterizing this package of STIX content. + + + + + Characterizes one or more cyber observables. + + + + + Characterizes one or more cyber threat Indicators. + + + + + Characterizes one or more cyber threat adversary Tactics, Techniques or Procedures. + + + + + Characterizes one or more potential targets for exploitation. + + + + + Characterizes one or more cyber threat Incidents. + + + + + Characterizes Courses of Action to be taken in regards to one of more cyber threats. + + + + + Characterizes one or more cyber threat Campaigns. + + + + + Characterizes one or more cyber Threat Actors. + + + + + + Specifies a globally unique identifier for this STIX Package. + + + + + Specifies a globally unique identifier of a STIX Package specified elsewhere. + + + + + Specifies the relevant STIX schema version for this content. + + + + + + An enumeration of all versions of STIX package types valid in the current release of STIX. + + + + + + + + The STIXHeaderType provides a structure for characterizing a package of STIX content. + + + + + The Title field provides a simple title for this STIX Package. + + + + + + The Package_Intent field characterizes the intended purpose or use for this package of STIX content. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is PackageIntentVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + The Description field provides a description of this package of STIX content. + + + + + Specifies the relevant handling guidance for this STIX_Package. The valid marking scope is the nearest STIXPackageType ancestor of this Handling element and all its descendants. + + + + + The Information_Source field details the source of this entry, including time information as well as information about the producer, contributors, tools, and references. + + + + + + + + + + + Characterizes a single cyber threat Indicator. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is IndicatorType in the http://stix.mitre.org/Indicator-2 namespace. This type is defined in the indicator.xsd file or at the URL http://stix.mitre.org/XMLSchema/indicator/2.0/indicator.xsd. + + + + + + + + + + + Characterizes a single cyber threat adversary Tactic, Technique or Procedure. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is TTPType in the http://stix.mitre.org/TTP-1 namespace. This type is defined in the ttp.xsd file or at the URL http://stix.mitre.org/XMLSchema/ttp/1.0/ttp.xsd. + + + + + + The Kill_Chains field characterizes specific Kill Chain definitions for reference within specific TTP entries, Indicators and elsewhere. + + + + + + + + + + Identifies or characterizes a single cyber threat Incident. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is IncidentType in the http://stix.mitre.org/Incident-1 namespace. This type is defined in the incident.xsd file or at the URL http://stix.mitre.org/XMLSchema/incident/1.0/incident.xsd. + + + + + + + + + + + The Course_Of_Action field characterizes a Course of Action to be taken in regards to one of more cyber threats. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is CourseOfActionType in the http://stix.mitre.org/CourseOfAction-1 namespace. This type is defined in the course_of_action.xsd file or at the URL http://stix.mitre.org/XMLSchema/course_of_action/1.0/course_of_action.xsd. + + + + + + + + + + + Characterizes a single cyber threat Campaign. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is CampaignType in the http://stix.mitre.org/Campaign-1 namespace. This type is defined in the campaign.xsd file or at the URL http://stix.mitre.org/XMLSchema/campaign/1.0/campaign.xsd. + + + + + + + + + + + Characterizes a single cyber Threat Actor. + + This field is implemented through the xsi:type extension mechanism. The default and strongly recommended type is ThreatActorType in the http://stix.mitre.org/ThreatActor-1 namespace. This type is defined in the threat_actor.xsd file or at the URL http://stix.mitre.org/XMLSchema/threat_actor/1.0/threat_actor.xsd. + + + + + + diff --git a/stix_validator/schema/stix_default_vocabularies.xsd b/stix_validator/schema/stix_default_vocabularies.xsd new file mode 100755 index 0000000..513c905 --- /dev/null +++ b/stix_validator/schema/stix_default_vocabularies.xsd @@ -0,0 +1,1578 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Default Vocabularies + 1.0.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) - Schematic implementation for controlled vocabularies used in the Structured Threat Information eXchange format. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + + The PackageIntentVocabType is the default STIX vocabulary for Package Intent. + + Note that this vocabulary is under development. Feedback is appreciated and should be sent to the STIX discussion list. + + + + + + + + + + + + + + + The default set of values to use for a package intent in STIX. + + 1.0 + + + + + + Package is intended to convey a broad characterization of a threat across multiple facets. + + + + + Package is intended to convey a broad characterization of a threat across multiple facets expressed as a cohesive report. + + + + + Package is intended to convey mainly indicators. + + + + + Package is intended to convey mainly phishing indicators. + + + + + Package is intended to convey mainly network watchlist indicators. + + + + + Package is intended to convey mainly malware artifact indicators. + + + + + Package is intended to convey mainly network activity indicators. + + + + + Package is intended to convey mainly endpoint characteristics (hashes, registry values, installed software, known vulnerabilities, etc.) indicators. + + + + + Package is intended to convey mainly a characterization of one or more campaigns. + + + + + Package is intended to convey mainly a characterization of one or more threat actors. + + + + + Package is intended to convey mainly a characterization of one or more exploits. + + + + + Package is intended to convey mainly a characterization of one or more attack patterns. + + + + + Package is intended to convey mainly a characterization of one or more malware instances. + + + + + Package is intended to convey mainly a characterization of attacker infrastructure. + + + + + Package is intended to convey mainly a characterization of attacker tools. + + + + + Package is intended to convey mainly a set of courses of action. + + + + + Package is intended to convey mainly information about one or more incidents. + + + + + Package is intended to convey mainly information about instantial observations (cyber observables). + + + + + Package is intended to convey mainly information about instantial email observations (email cyber observables). + + + + + Package is intended to convey a set of malware samples. + + + + + + + + The HighMediumLowVocabType is the default STIX vocabulary for expressing basic values that may be high, medium, low, none, or unknown. + + + + + + + + + + + + + + The default set of values to use for expressing a high/medium/low statement in STIX. + + 1.0 + + + + + + + + + + + + + + + The MalwareTypeVocabType is the default STIX vocabulary for expressing types of malware instances. + + Note that this vocabulary is under development. Feedback is appreciated and should be sent to the STIX discussion list. + + + + + + + + + + + + + + + The default set of malware types to use for characterizing a malware instance in STIX. + + + 1.0 + The initial version of this enumeration was contributed by iSight Partners, Inc. and is used with their permission. + + + + + + + + + + + + + + + + + + + + + + + + + + + + The IndicatorTypeVocabType is the default STIX vocabulary for expressing indicator types. + + Note that this vocabulary is under development. Feedback is appreciated and should be sent to the STIX discussion list. + + + + + + + + + + + + + + + The default set of Indicator types to use for characterizing Indicators in STIX. + + 1.0 + + + + + + Indicator describes suspected malicious e-mail (phishing, spear phishing, infected, etc.). + + + + + Indicator describes a set of suspected malicious IP addresses or IP blocks. + + + + + Indicator describes a set of hashes for suspected malicious files. + + + + + Indicator describes a set of suspected malicious domains. + + + + + Indicator describes a set of suspected malicious URLS. + + + + + Indicator describes the effects of suspected malware. + + + + + Indicator describes suspected command and control activity or static indications. + + + + + Indicator describes suspected anonymization techniques (Proxy, TOR, VPN, etc.). + + + + + Indicator describes suspected exfiltration techniques or behavior. + + + + + Indicator describes suspected malicious host characteristics. + + + + + + + + The COAStageVocabType is the default STIX vocabulary for expressing the stages of the threat management lifecycle that a COA is applicable to. + + + + + + + + + + + + + + The default set of stages of the threat management lifecycle that a COA may be applicable to. + + 1.0 + + + + + + This COA is applicable to the "Remedy" stage of the threat management lifecycle, meaning it may be applied proactively to prevent future threats. + + + + + This COA is applicable to the "Response" stage of the threat management lifecycle, meaning it may be applied as an immediate reaction to an ongoing threat. + + + + + + + + The CampaignStatusVocabType is the default STIX vocabulary for expressing the status of a campaign. + + + + + + + + + + + + + + The default list of possible statuses that a campaign might have. + + 1.0 + + + + + + This campaign is currently taking place. + + + + + This campaign occurred in the past and is currently not taking place. + + + + + This campaign is expected to take place in the future. + + + + + + + + The IncidentStatusVocabType is the default STIX vocabulary for expressing the status of an incident. + + + + + + + + + + + + + + The default list of possible statuses that an incident might have. + + 1.0 + + + + + + + + + + + + + + + + + + + The SecurityCompromiseVocabType is the default STIX vocabulary for expressing whether or not an incident resulted in a security compromise. + + + + + + + + + + + + + + + The possible values for expressing whether an incident resulted in a security compromise. + + + 1.0 + This vocabulary is a part of the VERIS framework and is used with their permission. + + + + + + It has been confirmed that this incident resulted in a security compromise. + + + + + It is suspected that this incident resulted in a security compromise. + + + + + It has been confirmed that this incident did not result in a security compromise. + + + + + It is not known whether this incident resulted in a security compromise. + + + + + + + + The DiscoveryMethodVocabType is the default STIX vocabulary for expressing how an incident was discovered. + + + + + + + + + + + + + + + The possible values for expressing how an incident was discovered. + + + 1.0 + This vocabulary is a part of the VERIS framework and is used with their permission. + + + + + + This incident was disclosed by the threat agent (e.g. public brag, private blackmail). + + + + + This incident was discovered through external fraud detection means (e.g. CPP). + + + + + This incident was reported by a managed security event monitoring service. + + + + + This incident was reported by law enforcement. + + + + + This incident was reported by a customer or partner affected by the incident. + + + + + This incident was reported by an unrelated third party. + + + + + This incident was discovered during an external security audit or scan. + + + + + This incident was discovered by an antivirus system. + + + + + This incident was discovered in the course of investigating a separate incident. + + + + + This incident was discovered in the course of a financial audit and/or reconciliation process. + + + + + This incident was discovered through internal fraud detection means. + + + + + This incident was discovered a host-based IDS or file integrity monitoring. + + + + + This incident was discovered by an internal IT audit or scan. + + + + + This incident was discovered during a log review process or by a SIEM. + + + + + This incident was discovered by a network-based intrustion detection/prevention system. + + + + + This incident was discovered by a physical security alarm. + + + + + This incident was reported by a user. + + + + + It is not known how this incident was discovered. + + + + + + + + The AvailabilityLossTypeVocabType is the default STIX vocabulary for expressing the type of availability that was lost due to an incident. + + + + + + + + + + + + + + + The possible values for expressing the type of availability that was lost due to an incident. + + + 1.0 + This vocabulary is a part of the VERIS framework and is used with their permission. + + + + + + The information was destroyed or wiped. + + + + + Availability to the information was lost. + + + + + Availability to the information was interrupted. + + + + + Availability to the information was degraded. + + + + + Availability loss type is acceleration. + + + + + Availability to the information is obscured. + + + + + The availability loss type is not known. + + + + + + + + The LossDurationVocabType is the default STIX vocabulary for expressing the approximate length of time of a loss due to an incident. + + + + + + + + + + + + + + + The possible values for expressing the type of availability that was lost due to an incident. + + + 1.0 + + + + + + The loss is permanent. + + + + + The loss lasted for weeks. + + + + + The loss lasted for days. + + + + + The loss lasted for hours. + + + + + The loss lasted for minutes. + + + + + The loss lasted for seconds. + + + + + The loss duration is not known. + + + + + + + + The OwnershipClassVocabType is the default STIX vocabulary for expressing the type of ownership of an asset. + + + + + + + + + + + + + + + The possible values for expressing the ownership class of an object. + + + 1.0 + + + + + + The asset is owned internally. + + + + + The asset is owned by an employee. + + + + + The asset is owned by a partner. + + + + + The asset is owned by a customer. + + + + + The asset ownership class is unknown. + + + + + + + + The ManagementClassVocabType is the default STIX vocabulary for expressing the type of management of an asset. + + + + + + + + + + + + + + + The possible values for expressing the management class of an object. + + + 1.0 + + + + + + The asset is managed internally. + + + + + The asset is managed externally. + + + + + The asset is co-managed. + + + + + The asset management class is unknown. + + + + + + + + The LocationClassVocabType is the default STIX vocabulary for expressing the location of an asset. + + + + + + + + + + + + + + + The possible values for expressing the location class of an object. + + + 1.0 + + + + + + The asset is located internally. + + + + + The asset is located externally. + + + + + The asset is co-located. + + + + + The asset is mobile. + + + + + The asset location is unknown. + + + + + + + + The ImpactQualificationVocabType is the default STIX vocabulary for expressing the subjective level of impact of an incident. + + + + + + + + + + + + + + + The possible values for expressing the impact level of an incident. + + + 1.0 + This vocabulary is a part of the VERIS framework and is used with their permission. + + + + + + The impact is absorbed by normal activities. + + + + + There are limited “hard costs”, but the impact is felt through having to deal with the incident rather than conducting normal duties. + + + + + Real, somewhat serious effect on the "bottom line". + + + + + Real and serious effect on the “bottom line” and/or long-term ability to generate revenue. + + + + + A business-ending event. + + + + + The impact qualification is unknown. + + + + + + + + The ImpactRatingVocabType is the default STIX vocabulary for expressing the level of impact due to an incident. + + + + + + + + + + + + + + + The possible values for expressing the level of impact due to a loss. + + + 1.0 + This vocabulary is a part of the VERIS framework and is used with their permission. + + + + + + There was no impact. + + + + + There was a minor impact. + + + + + There was a moderate impact. + + + + + There was a major impact. + + + + + The impact is not known. + + + + + + + + The AssetTypeVocabType is the default STIX vocabulary for expressing the type of an asset. + + + + + + + + + + + + + + + The possible values for types of assets. + + + 1.0 + This vocabulary is a part of the VERIS framework and is used with their permission. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The AttackerInfrastructureTypeVocabType is the default STIX vocabulary for expressing the type of infrastructure an attacker uses. + + + + + + + + + + + + + + + The possible values for types of attacker infrastructure. + + + 1.0 + The initial version of this enumeration was contributed by iSight Partners, Inc. and is used with their permission. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The SystemTypeVocabType is the default STIX vocabulary for expressing the type of a system. + + + + + + + + + + + + + + + The possible values for types of systems. + + + 1.0 + The initial version of this enumeration was contributed by iSight Partners, Inc. and is used with their permission. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The InformationTypeVocabType is the default STIX vocabulary for expressing the type of information. + + + + + + + + + + + + + + + The possible values for types of information. + + + 1.0 + The initial version of this enumeration was contributed by iSight Partners, Inc. and is used with their permission. + + + + + + + + + + + + + + + + + + The ThreatActorTypeVocabType is the default STIX vocabulary for expressing the type of a threat actor. + + + + + + + + + + + + + + + The possible values for types of threat actors. + + + 1.0 + The initial version of this enumeration was contributed by iSight Partners, Inc. and is used with their permission. + + + + + + + + + + + + + + + + + + + + + + + + + + The MotivationVocabType is the default STIX vocabulary for expressing the motivation of a threat actor. + + + + + + + + + + + + + + + The possible values for motivations of a threat actor. + + + 1.0 + The initial version of this enumeration was contributed by iSight Partners, Inc. and is used with their permission. + + + + + + + + + + + + + + + + + + + + + + + The IntendedEffectVocabType is the default STIX vocabulary for expressing the intended effect of a threat actor. + + + + + + + + + + + + + + + The possible values for effects intended by a threat actor. + + + 1.0 + The initial version of this enumeration was contributed by iSight Partners, Inc. and is used with their permission. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The PlanningAndOperationalSupportVocabType is the default STIX vocabulary for expressing the planning and operational support functions of a threat actor. + + + + + + + + + + + + + + + The possible values for types of planning and operational support functions of a threat actor. + + + 1.0 + The initial version of this enumeration was contributed by iSight Partners, Inc. and is used with their permission. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The IncidentEffectVocabType is the default STIX vocabulary for expressing the possible effects of an incident. + + + + + + + + + + + + + + + The possible values for types of possible effects of an incident. + + + 1.0 + The initial version of this enumeration was contributed by iSight Partners, Inc. and is used with their permission. + + + + + + + + + + + + + + + + + + + + + + + + The AttackerToolTypeVocab-1.0 is the default STIX vocabulary for expressing types of attacker tools. + + Note that this vocabulary is under development. Feedback is appreciated and should be sent to the STIX discussion list. + + + + + + + + + + + + + + + + The possible values for types of attacker tools. + + + 1.0 + The initial version of this enumeration was contributed by iSight Partners, Inc. and is used with their permission. + + + + + + + + + + + + + + + + The IncidentCategoryVocabType is the default STIX vocabulary for expressing the possible categories of an incident. + + + + + + + + + + + + + + + The possible values for types of possible categories of an incident. + + + 1.0 + This vocabulary is taken from the US-CERT Federal Incident Reporting Guidelines Incident Categories. + + + + + + This category is used during state, federal, national, international exercises and approved activity testing of internal/external network defenses or responses. + + + + + In this category an individual gains logical or physical access without permission to a federal agency network, system, application, data, or other resource. + + + + + An attack that successfully prevents or impairs the normal authorized functionality of networks, systems or applications by exhausting resources. This activity includes being the victim or participating in the DoS. + + + + + Installation of malicious software (e.g., virus, worm, Trojan horse, or other code-based malicious entity) that infects an operating system or application. Agencies are NOT required to report malicious logic that has been successfully quarantined by antivirus (AV) software. + + + + + A person violates acceptable computing use policies. + + + + + This category includes any activity that seeks to access or identify a federal agency computer, open ports, protocols, service, or any combination for later exploit. This activity does not directly result in a compromise or denial of service. + + + + + Unconfirmed incidents that are potentially malicious or anomalous activity deemed by the reporting entity to warrant further review. + + + + + + + + The LossPropertyVocabType is the default STIX vocabulary for expressing the possible properties of a loss. + + + + + + + + + + + + + + + The possible values for properties of a loss. + + + 1.0 + + + + + + + + + + + diff --git a/stix_validator/schema/test.xsd b/stix_validator/schema/test.xsd new file mode 100755 index 0000000..b38f883 --- /dev/null +++ b/stix_validator/schema/test.xsd @@ -0,0 +1,15 @@ + + + + + + + + + + + + + + + diff --git a/stix_validator/schema/threat_actor.xsd b/stix_validator/schema/threat_actor.xsd new file mode 100755 index 0000000..cd66ccc --- /dev/null +++ b/stix_validator/schema/threat_actor.xsd @@ -0,0 +1,173 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX Threat Actor + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) - ThreatActor - Schematic implementation for the Threat Actor construct within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + + Identification or characterization of the adversary + + + + + + + + + + The Title field provides a simple title for this ThreatActor. + + + + + + The Identity field characterizes the identity of this Threat Actor. + + This field is implemented through the xsi:type extension mechanism. The default type is CIQIdentity3.0InstanceType in the http://stix.mitre.org/extensions/Identity#CIQIdentity3.0-1 namespace. This type is defined in the extensions/identity/ciq_identity.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/identity/ciq_identity/1.0/ciq_identity.xsd. + + Those who wish to express a simple name may also do so by not specifying an xsi:type and using the Name field. + + + + + + + The Type field characterizes the type(s) of this threat actor. It may be used multiple times to capture multiple types. + + It is implemented through the StatementType, which allows for the expression of a statement in a vocabulary (Value), a description of the statement (Description), a confidence in the statement (Confidence), and the source of the statement (Source). The default vocabulary type for the Value is ThreatActorTypeVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Type field characterizes the motivations of this threat actor. It may be used multiple times to capture multiple motivations. + + It is implemented through the StatementType, which allows for the expression of a statement in a vocabulary (Value), a description of the statement (Description), a confidence in the statement (Confidence), and the source of the statement (Source). The default vocabulary type for the Value is MotivationVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Intended_Effect field specifies the suspected intended effect for this Threat Actor. + + It is implemented through the StatementType, which allows for the expression of a statement in a vocabulary (Value), a description of the statement (Description), a confidence in the statement (Confidence), and the source of the statement (Source). The default vocabulary type for the Value is IntendedEffectVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Planning_And_Operational_Support field specifies the suspected planning and operational support performed by this threat actor. + + It is implemented through the StatementType, which allows for the expression of a statement in a vocabulary (Value), a description of the statement (Description), a confidence in the statement (Confidence), and the source of the statement (Source). The default vocabulary type for the Value is PlanningAndOperationalSupportVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + The Observed_TTPs field specifies the TTPs that this Threat Actor has been observed to leverage. + + + + + The Associated_Campaigns field specifies any known Campaigns attributed to this Threat Actor. + + + + + The Associated_Actors field specifies other Threat Actors asserted to be associated with this Threat Actor. + + + + + The Handling field specifies the appropriate data handling markings for the elements of this Threat Actor characterization. The valid marking scope is the nearest ThreatActorBaseType ancestor of this Handling element and all its descendants. + + + + + The Confidence field characterizes the level of confidence held in the characterization of this Threat Actor. + + + + + The Information_Source field details the source of this entry. + + + + + + Specifies the relevant STIX-ThreatActor schema version for this content. + + + + + + + + + An enumeration of all versions of the Threat Actor type valid in the current release of STIX. + + + + + + + + + + + + The Associated_Actor field specifies another Threat Actor asserted to be associated with this Threat Actor. + + + + + + + + + + + + + The Associated_Campaign field specifies a known Campaign attributed to this Threat Actor. + + + + + + + + + + + + + The Observed_TTP field specifies a TTP that this Threat Actor has been observed to leverage. + + + + + + + diff --git a/stix_validator/schema/ttp.xsd b/stix_validator/schema/ttp.xsd new file mode 100755 index 0000000..3bae460 --- /dev/null +++ b/stix_validator/schema/ttp.xsd @@ -0,0 +1,340 @@ + + + + This schema was originally developed by The MITRE Corporation. The STIX XML Schema implementation is maintained by The MITRE Corporation and developed by the open STIX Community. For more information, including how to get involved in the effort and how to submit change requests, please visit the STIX website at http://stix.mitre.org. + + STIX TTP + 1.0 + 04/08/2013 9:00:00 AM + Structured Threat Information eXpression (STIX) - TTP - Schematic implementation for the TTP construct within the STIX structured cyber threat expression language architecture. + Copyright (c) 2012-2013, The MITRE Corporation. All rights reserved. The contents of this file are subject to the terms of the STIX License located at http://stix.mitre.org/about/termsofuse.html. See the STIX License for the specific language governing permissions and limitations for use of this schema. When distributing copies of the STIX Schema, this license header must be included. + + + + + + + + + The TTP field characterizes specific details of observed or potential attacker Tactics, Techniques and Procedures. + + + + + + TTPType characterizes an individual adversary TTP. + + + + + + + The Title field provides a simple title for this TTP. + + + + + The Description field provides an unstructured description of the TTP. + + + + + + The Intended_Effect field specifies the suspected intended effect for this TTP. + + It is implemented through the StatementType, which allows for the expression of a statement in a vocabulary (Value), a description of the statement (Description), a confidence in the statement (Confidence), and the source of the statement (Source). The default vocabulary type for the Value is IntendedEffectVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + Behavior describes the attack patterns, malware, or exploits that the attacker leverages to execute this TTP. + + + + + Resources describe the infrastructure or tools that the adversary uses to execute this TTP. + + + + + The Victim_Targeting field characterizes the people, organizations, information or access being targeted. + + + + + The Exploit_Targets field characterizes potential vulnerability, weakness or configuration targets for exploitation by this TTP. + + + + + The Related_TTPs field specifies other TTPs asserted to be related to this cyber threat TTP. + + + + + The Kill_Chain_Phases field specifies one or more Kill Chain phases associated with this TTP item. + + + + + The Information_Source field details the source of this entry. + + + + + The Kill_Chains field characterizes specific Kill Chain definitions for reference within specific TTP entries, Indicators and elsewhere. + + + + + Specifies the relevant handling guidance for this TTP. The valid marking scope is the nearest TTPBaseType ancestor of this Handling element and all its descendants. + + + + + + Specifies the relevant STIX-TTP schema version for this content. + + + + + + + + + An enumeration of all versions of the TTP type valid in the current release of STIX. + + + + + + + + + Captures prose information about an individual attack pattern as well as a CAPEC reference. + + In addition to capturing basic information, this type is intended to be extended to enable the structured description of an attack pattern instance using the XML Schema extension feature. The STIX default extension uses the Common Attack Pattern Enumeration and Classification (CAPEC) schema to do so. The extension that defines this is captured in the CAPEC2.5InstanceType in the http://stix.mitre.org/extensions/AP#CAPEC2.5-1 namespace. This type is defined in the extensions/attack_pattern/capec_2.5.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/attack_pattern/capec_2.5/1.0/capec_2.5.xsd. + + + + + + The Description field provides an unstructured description of an individual Attack Pattern. + + + + + + This field specifies a reference to a particular entry within the Common Attack Pattern Enumeration and Classification (CAPEC) + + + + + + + + + + + + Captures basic information about an individual malware instance. + + In addition to capturing basic information, this type is intended to be extended to enable the structured description of a malware instance using the XML Schema extension feature. The STIX default extension uses the Malware Attribute Enumeration and Classification (MAEC) schema to do so. The extension that defines this is captured in the MAECInstanceType in the http://stix.mitre.org/extensions/Malware#MAEC-1 namespace. This type is defined in the extensions/malware/maec-4.0.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/malware/maec-4.0/1.0/maec-4.0.xsd. + + + + + + + The Type field provides a characterization of what type of malware this MalwareInstance is. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is MalwareTypeVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Name field specifies a name associated with this MalwareInstance. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. No default vocabulary type has been defined for STIX 1.0. Users may either define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a free string field. + + + + + + The Description field provides an unstructured description of an individual Malware instance. + + + + + + + + Characterizes a description of an individual exploit. + + In addition to capturing basic information, this type is intended to be extended to enable the structured description of an exploit using the XML Schema extension feature. No extension is provided by STIX to support this, however those wishing to represent structured exploit information may develop such an extension. + + + + + + The Description field provides an unstructured description of an individual Exploit instance. + + + + + + + + + + + The Related_TTP field specifies a single other TTP asserted to be related to this cyber threat TTP. + + + + + + + + + + + + The Type field represents the type of infrastructure being described. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is AttackerInfrastructureTypeVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + The Description field generally describes specific classes or instances of infrastructure utilized for cyber attack. + + + + + The Observable_Characterization field provides structured characterization of the cyber observables detailing specific classes or instances of infrastructure utilized for cyber attack. + + + + + + + + + + The Tool field specifies a single Tool leveraged by this TTP item. + + The Type field under this field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is AttackerToolTypeVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + + + + The Exploit field specifies a single Exploit for this TTP item. + + + + + + + + + The Malware_Instance field specifies a single instance of Malware for this TTP item. + + + + + + + + + The Attack_Pattern field specifies a single Attack Pattern for this TTP item. + + + + + + + + + The Tools field specifies one or more Tools leveraged by this TTP item. + + + + + The Infrastructure field characterizes specific classes or instances of infrastructure observed to have been utilized for cyber attack. + + + + + + + + + The Attack_Patterns field specifies one or more Attack Patterns for this TTP item. + + + + + The Malware field specifies one or more instances of Malware for this TTP item. + + + + + The Exploits field specifies one or more Exploits for this TTP item. + + + + + + + + + + The Identity field characterizes information about the identity or characteristics of the targeted people or organizations. + + This field is implemented through the xsi:type extension mechanism. The default type is CIQIdentity3.0InstanceType in the http://stix.mitre.org/extensions/Identity#CIQIdentity3.0-1 namespace. This type is defined in the extensions/identity/ciq_identity_3.0.xsd file or at the URL http://stix.mitre.org/XMLSchema/extensions/identity/ciq_identity_3.0/1.0/ciq_identity_3.0.xsd. + + + + + + + The Targeted_Systems field characterizes a type of system that is targeted. It may be included multiple times to specify multiple types of targeted systems. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is SystemTypeVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + + The Targeted_Systems field characterizes a type of information that is targeted. It may be included multiple times to specify multiple types of targeted information. + + This field is implemented through the xsi:type controlled vocabulary extension mechanism. The default vocabulary type is InformationTypeVocab-1.0 in the http://stix.mitre.org/default_vocabularies-1 namespace. This type is defined in the stix_default_vocabularies.xsd file or at the URL http://stix.mitre.org/XMLSchema/default_vocabularies/1.0.0/stix_default_vocabularies.xsd . + + Users may also define their own vocabulary using the type extension mechanism, specify a vocabulary name and reference using the attributes, or simply use this as a string field. + + + + + + diff --git a/stix_validator/sdv.py b/stix_validator/sdv.py new file mode 100755 index 0000000..6bd8fac --- /dev/null +++ b/stix_validator/sdv.py @@ -0,0 +1,69 @@ +#!/usr/bin/env python + +# Copyright (c) 2013, The MITRE Corporation. All rights reserved. +# See LICENSE.txt for complete terms. +''' +STIX Document Validator (sdv) - validates STIX v1.0 instance documents. +''' + +import os +import argparse +from validator import XmlValidator + +def get_files_to_validate(dir): + '''Return a list of xml files under a directory''' + to_validate = [] + for top, dirs, files in os.walk(dir): + for fn in files: + if fn.endswith('.xml'): + fp = os.path.join(top, fn) + to_validate.append(fp) + + return to_validate + +def error(msg): + '''Print the error message and exit(1)''' + print "[!] %s" % (msg) + exit(1) + +def main(): + parser = argparse.ArgumentParser(description="STIX Document Validator (sdv) - validated STIX v1.0 instance documents") + parser.add_argument("--schema-dir", dest="schema_dir", default=None, help="Path to directory containing all necessary schemas for validation") + parser.add_argument("--input-file", dest="infile", default=None, help="Path to STIX instance document to validate") + parser.add_argument("--input-dir", dest="indir", default=None, help="Path to directory containing STIX instance documents to validate") + parser.add_argument("--use-schemaloc", dest="use_schemaloc", action='http://github.com/store_true', default=False, help="Use schemaLocation attribute to determine schema locations.") + + args = parser.parse_args() + + if not(args.infile or args.indir): + error("Must provide either --input-file or --input-dir argument") + + if args.infile and args.indir: + error('Must provide either --input-file or --input-dir argument, but not both') + + if not(args.schema_dir or args.use_schemaloc): + error("Must provide either --use-schemaloc or --schema-dir") + + if args.schema_dir and args.use_schemaloc: + error("Most provide either --use-schemaloc or --schema-dir, but not both") + + if args.infile: + to_validate = [args.infile] + else: + to_validate = get_files_to_validate(args.indir) + + if len(to_validate) > 0: + print "[-] Processing %s files" % (len(to_validate)) + ssv = XmlValidator(schema_dir=args.schema_dir, use_schemaloc=args.use_schemaloc) + for fp in to_validate: + with open(fp, 'rb') as f: + (result, msg) = ssv.validate(f) + if result: + print "[+] %s : VALID" % (fp) + else: + print "[!] %s : INVALID : %s" % (fp, msg) + +if __name__ == '__main__': + main() + + diff --git a/stix_validator/validator.py b/stix_validator/validator.py new file mode 100755 index 0000000..791f728 --- /dev/null +++ b/stix_validator/validator.py @@ -0,0 +1,154 @@ +# Copyright (c) 2013, The MITRE Corporation. All rights reserved. +# See LICENSE.txt for complete terms. + +import os +from collections import defaultdict +from lxml import etree as et + +NS_XML_SCHEMA_INSTANCE = "http://www.w3.org/2001/XMLSchema-instance" +NS_XML_SCHEMA = "http://www.w3.org/2001/XMLSchema" + +class XmlValidator(object): + + def __init__(self, schema_dir=None, use_schemaloc=False): + self.__imports = self._build_imports(schema_dir) + self.__use_schemaloc = use_schemaloc + + def _get_target_ns(self, fp): + '''Returns the target namespace for a schema file + + Keyword Arguments + fp - the path to the schema file + ''' + tree = et.parse(fp) + root = tree.getroot() + return root.attrib['targetNamespace'] # throw an error if it doesn't exist...we can't validate + + def _get_include_base_schema(self, list_schemas): + '''Returns the root schema which defines a namespace. + + Certain schemas, such as OASIS CIQ use xs:include statements in their schemas, where two schemas + define a namespace (e.g., XAL.xsd and XAL-types.xsd). This makes validation difficult, when we + must refer to one schema for a given namespace. + + To fix this, we attempt to find the root schema which includes the others. We do this by seeing + if a schema has an xs:include element, and if it does we assume that it is the parent. This is + totally wrong and needs to be fixed. Ideally this would build a tree of includes and return the + root node. + + Keyword Arguments: + list_schemas - a list of schema file paths that all belong to the same namespace + ''' + parent_schema = None + tag_include = "{%s}include" % (NS_XML_SCHEMA) + + for fn in list_schemas: + tree = et.parse(fn) + root = tree.getroot() + includes = root.findall(tag_include) + + if len(includes) > 0: # this is a hack that assumes if the schema includes others, it is the base schema for the namespace + return fn + + return parent_schema + + def _build_imports(self, schema_dir): + '''Given a directory of schemas, this builds a dictionary of schemas that need to be imported + under a wrapper schema in order to enable validation. This returns a dictionary of the form + {namespace : path to schema}. + + Keyword Arguments + schema_dir - a directory of schema files + ''' + if not schema_dir: + return None + + imports = defaultdict(list) + for top, dirs, files in os.walk(schema_dir): + for f in files: + if f.endswith('.xsd'): + fp = os.path.join(top, f) + target_ns = self._get_target_ns(fp) + imports[target_ns].append(fp) + + for k,v in imports.iteritems(): + if len(v) > 1: + base_schema = self._get_include_base_schema(v) + imports[k] = base_schema + else: + imports[k] = v[0] + + return imports + + def _build_wrapper_schema(self, import_dict): + '''Creates a wrapper schema that imports all namespaces defined by the input dictionary. This enables + validation of instance documents that refer to multiple namespaces and schemas + + Keyword Arguments + import_dict - a dictionary of the form {namespace : path to schema} that will be used to build the list of xs:import statements + ''' + schema_txt = '''''' + root = et.fromstring(schema_txt) + + tag_import = "{%s}import" % (NS_XML_SCHEMA) + for ns, list_schemaloc in import_dict.iteritems(): + schemaloc = list_schemaloc + schemaloc = schemaloc.replace("\\", "/") + attrib = {'namespace' : ns, 'schemaLocation' : schemaloc} + el_import = et.Element(tag_import, attrib=attrib) + root.append(el_import) + + return root + + def _extract_schema_locations(self, root): + schemaloc_dict = {} + + tag_schemaloc = "{%s}schemaLocation" % (NS_XML_SCHEMA_INSTANCE) + schemaloc = root.attrib[tag_schemaloc].split() + schemaloc_pairs = zip(schemaloc[::2], schemaloc[1::2]) + + for ns, loc in schemaloc_pairs: + schemaloc_dict[ns] = loc + + return schemaloc_dict + + def validate(self, instance_doc): + '''Validates an instance documents. + + Returns a tuple of where the first item is the boolean validation + result and the second is the validation error if there was one. + + Keyword Arguments + instance_doc - a file-like object to be validated + ''' + if not(self.__use_schemaloc or self.__imports): + return (False, "No schemas to validate against! Try instantiating XmlValidator with use_schemaloc=True or setting the schema_dir") + + instance_doc = et.parse(instance_doc) + instance_root = instance_doc.getroot() + + if self.__use_schemaloc: + try: + required_imports = self._extract_schema_locations(instance_root) + except KeyError as e: + return (False, "No schemaLocation attribute set on instance document. Unable to validate") + else: + required_imports = {} + for prefix, ns in instance_root.nsmap.iteritems(): + schemaloc = self.__imports.get(ns) + if schemaloc: + required_imports[ns] = schemaloc + + if not required_imports: + return (False, "Unable to determine schemas to validate against") + + wrapper_schema_doc = self._build_wrapper_schema(import_dict=required_imports) + xmlschema = et.XMLSchema(wrapper_schema_doc) + + try: + xmlschema.assertValid(instance_doc) + return (True, None) + except Exception as e: + return (False, str(e)) + + \ No newline at end of file From c82290991485b2f0926f7cf3a4e639e3ddf8fa17 Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Thu, 12 Sep 2013 13:37:32 -0400 Subject: [PATCH 02/14] added STIXValidator class which performs best practice guidance check as well as schema validation --- stix_validator/sdv.py | 84 ++++++++++++++++-- stix_validator/validator.py | 169 ++++++++++++++++++++++++++++++++++-- 2 files changed, 238 insertions(+), 15 deletions(-) diff --git a/stix_validator/sdv.py b/stix_validator/sdv.py index 6bd8fac..09922d3 100755 --- a/stix_validator/sdv.py +++ b/stix_validator/sdv.py @@ -8,7 +8,7 @@ import os import argparse -from validator import XmlValidator +from validator import STIXValidator def get_files_to_validate(dir): '''Return a list of xml files under a directory''' @@ -26,12 +26,81 @@ def error(msg): print "[!] %s" % (msg) exit(1) +def print_result(fp, isvalid, validation_error, warnings): + if isvalid: + print "[+] %s : VALID" % (fp) + + if warnings: + duplicate_ids = warnings.get('duplicate_ids') + if duplicate_ids: + print ' [~] Nodes with duplicate ids' + for id_, list_nodes in duplicate_ids.iteritems(): + print ' [~] id: [%s]' % (id_) + for node in list_nodes: + print ' [%s] line: [%s]' % (node.tag, node.sourceline) + print + + missing_ids = warnings.get('missing_ids') + if missing_ids: + print ' [~] Nodes with missing ids' + for node in missing_ids: + print ' [~] [%s] line: [%s]' % (node.tag, node.sourceline) + print + + unresolved_idrefs = warnings.get('unresolved_idrefs') + if unresolved_idrefs: + print ' [~] Nodes with idrefs that do not resolve' + for node in unresolved_idrefs: + print ' [~] [%s] idref: [%s] line: [%s]' % (node.tag, node.attrib.get('idref'), node.sourceline) + print + + formatted_ids = warnings.get('id_format') + if formatted_ids: + print ' [~] Nodes with ids not formatted as [ns_prefix]:[object-type]-[GUID]' + for node in formatted_ids: + print ' [~] [%s] id: [%s] line: [%s]' % (node.tag, node.attrib.get('id'), node.sourceline) + print + + idrefs_with_content = warnings.get('idref_with_content') + if idrefs_with_content: + print ' [~] Nodes that declare idrefs but also contain content' + for node in idrefs_with_content: + print ' [~] [%s] idref: [%s] line: [%s]' % (node.tag, node.attrib.get('idref'), node.sourceline) + print + + indicator_suggestions = warnings.get('indicator_suggestions') + if indicator_suggestions: + print ' [~] Indicator suggestions' + for indicator_dict in indicator_suggestions: + node = indicator_dict['node'] + list_missing = [] + if not indicator_dict.get('title', True): + list_missing.append('Title') + if not indicator_dict.get('description', True): + list_missing.append('Description') + if not indicator_dict.get('type', True): + list_missing.append('Type') + if not indicator_dict.get('valid_time_position', True): + list_missing.append('Valid_Time_Position') + if not indicator_dict.get('indicated_ttp', True): + list_missing.append('Indicated_TTP') + if not indicator_dict.get('confidence', True): + list_missing.append('Confidence') + + print ' [~] id: [%s] line: [%s] missing: %s' % (indicator_dict.get('id'), node.sourceline, list_missing) + + else: + print "[!] %s : INVALID : [%s]" % (fp, str(validation_error)) + + + def main(): - parser = argparse.ArgumentParser(description="STIX Document Validator (sdv) - validated STIX v1.0 instance documents") + parser = argparse.ArgumentParser(description="STIX Document Validator") parser.add_argument("--schema-dir", dest="schema_dir", default=None, help="Path to directory containing all necessary schemas for validation") parser.add_argument("--input-file", dest="infile", default=None, help="Path to STIX instance document to validate") parser.add_argument("--input-dir", dest="indir", default=None, help="Path to directory containing STIX instance documents to validate") parser.add_argument("--use-schemaloc", dest="use_schemaloc", action='http://github.com/store_true', default=False, help="Use schemaLocation attribute to determine schema locations.") + parser.add_argument("--best-practices", dest="best_practices", action='http://github.com/store_true', default=False, help="Check that the document follows authoring best practices") args = parser.parse_args() @@ -54,16 +123,13 @@ def main(): if len(to_validate) > 0: print "[-] Processing %s files" % (len(to_validate)) - ssv = XmlValidator(schema_dir=args.schema_dir, use_schemaloc=args.use_schemaloc) + ssv = STIXValidator(schema_dir=args.schema_dir, use_schemaloc=args.use_schemaloc, best_practices=args.best_practices) for fp in to_validate: with open(fp, 'rb') as f: - (result, msg) = ssv.validate(f) - if result: - print "[+] %s : VALID" % (fp) - else: - print "[!] %s : INVALID : %s" % (fp, msg) + (isvalid, validation_error, best_practice_warnings) = ssv.validate(f) + print_result(fp, isvalid, validation_error, best_practice_warnings) if __name__ == '__main__': main() - + \ No newline at end of file diff --git a/stix_validator/validator.py b/stix_validator/validator.py index 791f728..6628d98 100755 --- a/stix_validator/validator.py +++ b/stix_validator/validator.py @@ -2,13 +2,13 @@ # See LICENSE.txt for complete terms. import os +import re from collections import defaultdict from lxml import etree as et -NS_XML_SCHEMA_INSTANCE = "http://www.w3.org/2001/XMLSchema-instance" -NS_XML_SCHEMA = "http://www.w3.org/2001/XMLSchema" - class XmlValidator(object): + NS_XML_SCHEMA_INSTANCE = "http://www.w3.org/2001/XMLSchema-instance" + NS_XML_SCHEMA = "http://www.w3.org/2001/XMLSchema" def __init__(self, schema_dir=None, use_schemaloc=False): self.__imports = self._build_imports(schema_dir) @@ -40,7 +40,7 @@ def _get_include_base_schema(self, list_schemas): list_schemas - a list of schema file paths that all belong to the same namespace ''' parent_schema = None - tag_include = "{%s}include" % (NS_XML_SCHEMA) + tag_include = "{%s}include" % (self.NS_XML_SCHEMA) for fn in list_schemas: tree = et.parse(fn) @@ -90,7 +90,7 @@ def _build_wrapper_schema(self, import_dict): schema_txt = '''''' root = et.fromstring(schema_txt) - tag_import = "{%s}import" % (NS_XML_SCHEMA) + tag_import = "{%s}import" % (self.NS_XML_SCHEMA) for ns, list_schemaloc in import_dict.iteritems(): schemaloc = list_schemaloc schemaloc = schemaloc.replace("\\", "/") @@ -103,7 +103,7 @@ def _build_wrapper_schema(self, import_dict): def _extract_schema_locations(self, root): schemaloc_dict = {} - tag_schemaloc = "{%s}schemaLocation" % (NS_XML_SCHEMA_INSTANCE) + tag_schemaloc = "{%s}schemaLocation" % (self.NS_XML_SCHEMA_INSTANCE) schemaloc = root.attrib[tag_schemaloc].split() schemaloc_pairs = zip(schemaloc[::2], schemaloc[1::2]) @@ -151,4 +151,161 @@ def validate(self, instance_doc): except Exception as e: return (False, str(e)) + +class STIXValidator(XmlValidator): + '''Schema validates STIX v1.0 documents and checks best practice guidance''' + __stix_version__ = "1.0" + + PREFIX_STIX_CORE = 'stix' + PREFIX_CYBOX_CORE = 'cybox' + PREFIX_STIX_INDICATOR = 'indicator' + + NS_STIX_CORE = "http://stix.mitre.org/stix-1" + NS_STIX_INDICATOR = "http://stix.mitre.org/Indicator-2" + NS_CYBOX_CORE = "http://cybox.mitre.org/cybox-2" + + NS_MAP = {PREFIX_CYBOX_CORE : NS_CYBOX_CORE, + PREFIX_STIX_CORE : NS_STIX_CORE, + PREFIX_STIX_INDICATOR : NS_STIX_INDICATOR} + + def __init__(self, schema_dir=None, use_schemaloc=False, best_practices=False): + super(STIXValidator, self).__init__(schema_dir, use_schemaloc) + self.best_practices = best_practices + + def _check_id_presence_and_format(self, instance_doc): + return_dict = {'no_id' : [], + 'format' : []} + + elements_to_check = ['stix:Campaign', + 'stix:Course_Of_Action', + 'stix:Exploit_Target', + 'stix:Incident', + 'stix:Indicator', + 'stix:STIX_Package', + 'stix:Thread_Actor', + 'stix:TTP', + 'cybox:Observable', + 'cybox:Object', + 'cybox:Event', + 'cybox:Action'] + + for tag in elements_to_check: + xpath = ".//%s" % (tag) + elements = instance_doc.xpath(xpath, namespaces=self.NS_MAP) + + for e in elements: + try: + if not re.match(r'\w+:\w+-', e.attrib['id']): # not the best regex + return_dict['format'].append(e) + except KeyError as ex: + return_dict['no_id'].append(e) + + return return_dict + + def _check_duplicate_ids(self, instance_doc): + dict_id_nodes = defaultdict(list) + dup_dict = {} + xpath_all_nodes_with_ids = "//*[@id]" + + all_nodes_with_ids = instance_doc.xpath(xpath_all_nodes_with_ids) + for node in all_nodes_with_ids: + dict_id_nodes[node.attrib['id']].append(node) + + for k,v in dict_id_nodes.iteritems(): + if len(v) > 1: + dup_dict[k] = v + + return dup_dict + + def _check_idref_resolution(self, instance_doc): + list_unresolved_ids = [] + xpath_all_idrefs = "//*[@idref]" + xpath_all_ids = "//@id" + + all_idrefs = instance_doc.xpath(xpath_all_idrefs) + all_ids = instance_doc.xpath(xpath_all_ids) + + for node in all_idrefs: + if node.attrib['idref'] not in all_ids: + list_unresolved_ids.append(node) + + return list_unresolved_ids + + def _check_idref_with_content(self, instance_doc): + list_nodes = [] + xpath = "//*[@idref]" + nodes = instance_doc.xpath(xpath) + + for node in nodes: + if node.text or len(node) > 0: + list_nodes.append(node) + + return list_nodes + + def _check_indicator_practices(self, instance_doc): + list_indicators = [] + xpath = "//%s:Indicator | %s:Indicator" % (self.PREFIX_STIX_CORE, self.PREFIX_STIX_INDICATOR) + + nodes = instance_doc.xpath(xpath, namespaces=self.NS_MAP) + for node in nodes: + dict_indicator = {} + if not node.attrib.get('idref'): # if this is not an idref node, look at its content + if node.find('{%s}Title' % (self.NS_STIX_INDICATOR)) is None: + dict_indicator['title'] = False + if node.find('{%s}Description' % (self.NS_STIX_INDICATOR)) is None: + dict_indicator['description'] = False + if node.find('{%s}Type' % (self.NS_STIX_INDICATOR)) is None: + dict_indicator['type'] = False + if node.find('{%s}Valid_Time_Position' % (self.NS_STIX_INDICATOR)) is None: + dict_indicator['valid_time_position'] = False + if node.find('{%s}Indicated_TTP' % (self.NS_STIX_INDICATOR)) is None: + dict_indicator['indicated_ttp'] = False + if node.find('{%s}Confidence' % (self.NS_STIX_INDICATOR)) is None: + dict_indicator['confidence'] = False + + if dict_indicator: + dict_indicator['id'] = node.attrib.get('id') + dict_indicator['node'] = node + list_indicators.append(dict_indicator) + + return list_indicators + + def check_best_practices(self, instance_doc): + instance_doc.seek(0) + tree = et.parse(instance_doc) + root = tree.getroot() + + list_unresolved_idrefs = self._check_idref_resolution(root) + dict_duplicate_ids = self._check_duplicate_ids(root) + dict_presence_and_format = self._check_id_presence_and_format(root) + list_idref_with_content = self._check_idref_with_content(root) + list_indicators = self._check_indicator_practices(root) + + return {'unresolved_idrefs' : list_unresolved_idrefs, + 'duplicate_ids' : dict_duplicate_ids, + 'missing_ids' : dict_presence_and_format['no_id'], + 'id_format' : dict_presence_and_format['format'], + 'idref_with_content' : list_idref_with_content, + 'indicator_suggestions' : list_indicators } + + def validate(self, instance_doc): + '''Validates a STIX document and checks best practice guidance if STIXValidator + was initialized with best_practices=True. + + Best practices will not be checked if the document is schema-invalid. + + Returns a tuple of (bool, str, dict) for (is valid, validation error, best practice suggestions). + + Keyword Arguments + instance_doc - a file-like object for a STIX instance document + ''' + (isvalid, validation_error) = super(STIXValidator, self).validate(instance_doc) + + if self.best_practices and isvalid: + best_practice_warnings = self.check_best_practices(instance_doc) + else: + best_practice_warnings = None + + return (isvalid, validation_error, best_practice_warnings) + \ No newline at end of file From 4a27ca81feed40e8b70e816c023f48821585a43e Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Wed, 11 Sep 2013 18:44:13 -0400 Subject: [PATCH 03/14] Update README.md --- stix_validator/README.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/stix_validator/README.md b/stix_validator/README.md index e69de29..ceaae17 100644 --- a/stix_validator/README.md +++ b/stix_validator/README.md @@ -0,0 +1,30 @@ +# STIX Document Validator (sdv) BETA +A python tool used to validate STIX v1.0 instance documents. For more information about the +Structured Thread Information eXpression, see http://stix.mitre.org. + +## Dependencies +The STIX Document Validator has the following dependencies: +* Python v2.7 http://python.org/download +* lxml >= v3.2.0 http://lxml.de/index.html#download + * libxml2 >= v2.9.1 http://www.xmlsoft.org/downloads.html + +## Use +The STIX Document Validator can validate a STIX v1.0 instance document against STIX v1.0 schemas +found locally or referenced remotely through the schemaLocation attribute. + +Validate against local schemas: +`python sdv.py --input-file stix_foo.xml --schema-dir schema` + +Validate using schemaLocation: +`python sdv.py --input-file --use-schemaloc` + +Validate a directory of STIX documents: +`python sdv.py --input-dir --schema-dir schema` + + +## Terms +BY USING THE STIX DOCUMENT VALIDATOR, YOU SIGNIFY YOUR ACCEPTANCE OF THE +TERMS AND CONDITIONS OF USE. IF YOU DO NOT AGREE TO THESE TERMS, DO NOT USE +THE STIX DOCUMENT VALIDATOR. + +For more information, please refer to the LICENSE.txt file From cb631113c9b7dd818e5751f6c3f91f1abb645115 Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Wed, 11 Sep 2013 18:49:25 -0400 Subject: [PATCH 04/14] Update README.md --- stix_validator/README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/stix_validator/README.md b/stix_validator/README.md index ceaae17..08d0bf7 100644 --- a/stix_validator/README.md +++ b/stix_validator/README.md @@ -21,6 +21,10 @@ Validate using schemaLocation: Validate a directory of STIX documents: `python sdv.py --input-dir --schema-dir schema` +## All STIX Documents? +The STIX Document Validator bundles a schema directory with it, which includes all STIX v1.0 +schema files. If an instance document uses constructs or languages defined by other schemas +a user must point the STIX Document Validator at those schemas in order to validate. ## Terms BY USING THE STIX DOCUMENT VALIDATOR, YOU SIGNIFY YOUR ACCEPTANCE OF THE From 4d4917b16052e919610b50590ba3c7ee4fd3574a Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Wed, 11 Sep 2013 18:54:32 -0400 Subject: [PATCH 05/14] Update README.md --- stix_validator/README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/stix_validator/README.md b/stix_validator/README.md index 08d0bf7..bd96aca 100644 --- a/stix_validator/README.md +++ b/stix_validator/README.md @@ -8,6 +8,10 @@ The STIX Document Validator has the following dependencies: * lxml >= v3.2.0 http://lxml.de/index.html#download * libxml2 >= v2.9.1 http://www.xmlsoft.org/downloads.html +**NOTE:** Older versions of libxml2 do not work properly and may result in undesirable behavior. +To see what version of libxml2 you have installed, execute the `xml2-config --version` command +and make sure you are running at least v2.9.1. + ## Use The STIX Document Validator can validate a STIX v1.0 instance document against STIX v1.0 schemas found locally or referenced remotely through the schemaLocation attribute. From 2c2a9200a55c55f38168d0b49f80e5682adc5dca Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Wed, 11 Sep 2013 19:01:20 -0400 Subject: [PATCH 06/14] Update README.md --- stix_validator/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/stix_validator/README.md b/stix_validator/README.md index bd96aca..de10adb 100644 --- a/stix_validator/README.md +++ b/stix_validator/README.md @@ -17,7 +17,7 @@ The STIX Document Validator can validate a STIX v1.0 instance document against S found locally or referenced remotely through the schemaLocation attribute. Validate against local schemas: -`python sdv.py --input-file stix_foo.xml --schema-dir schema` +`python sdv.py --input-file --schema-dir schema` Validate using schemaLocation: `python sdv.py --input-file --use-schemaloc` From 3f92a0d29a00981244ae4d955484ae4b202b1ac8 Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Thu, 12 Sep 2013 13:47:41 -0400 Subject: [PATCH 07/14] Update README.md --- stix_validator/README.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/stix_validator/README.md b/stix_validator/README.md index de10adb..ae16e24 100644 --- a/stix_validator/README.md +++ b/stix_validator/README.md @@ -14,7 +14,8 @@ and make sure you are running at least v2.9.1. ## Use The STIX Document Validator can validate a STIX v1.0 instance document against STIX v1.0 schemas -found locally or referenced remotely through the schemaLocation attribute. +found locally or referenced remotely through the schemaLocation attribute. It can also perform +some 'best practice' guidance checks. Validate against local schemas: `python sdv.py --input-file --schema-dir schema` @@ -25,6 +26,9 @@ Validate using schemaLocation: Validate a directory of STIX documents: `python sdv.py --input-dir --schema-dir schema` +Check 'best practice' guidance +`python sdv.py --input-file --best-practices` + ## All STIX Documents? The STIX Document Validator bundles a schema directory with it, which includes all STIX v1.0 schema files. If an instance document uses constructs or languages defined by other schemas From 8fe1ad771c42bc79edb95a055258cfd17701f233 Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Thu, 12 Sep 2013 14:03:33 -0400 Subject: [PATCH 08/14] fixed typo in STIXValidator --- stix_validator/validator.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/stix_validator/validator.py b/stix_validator/validator.py index 6628d98..6059505 100755 --- a/stix_validator/validator.py +++ b/stix_validator/validator.py @@ -182,7 +182,7 @@ def _check_id_presence_and_format(self, instance_doc): 'stix:Incident', 'stix:Indicator', 'stix:STIX_Package', - 'stix:Thread_Actor', + 'stix:Threat_Actor', 'stix:TTP', 'cybox:Observable', 'cybox:Object', From 9fff536b4d509d5ab0807bc1b10c38e2f9b5c2c4 Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Thu, 12 Sep 2013 14:25:09 -0400 Subject: [PATCH 09/14] added docstrings to STIXValidator class and changed returned dictionary in STIXValidator._check_indicator_practices() method. --- stix_validator/sdv.py | 18 ++-------- stix_validator/validator.py | 70 +++++++++++++++++++++++++++++++++---- 2 files changed, 65 insertions(+), 23 deletions(-) diff --git a/stix_validator/sdv.py b/stix_validator/sdv.py index 09922d3..d6bd7fc 100755 --- a/stix_validator/sdv.py +++ b/stix_validator/sdv.py @@ -72,22 +72,8 @@ def print_result(fp, isvalid, validation_error, warnings): if indicator_suggestions: print ' [~] Indicator suggestions' for indicator_dict in indicator_suggestions: - node = indicator_dict['node'] - list_missing = [] - if not indicator_dict.get('title', True): - list_missing.append('Title') - if not indicator_dict.get('description', True): - list_missing.append('Description') - if not indicator_dict.get('type', True): - list_missing.append('Type') - if not indicator_dict.get('valid_time_position', True): - list_missing.append('Valid_Time_Position') - if not indicator_dict.get('indicated_ttp', True): - list_missing.append('Indicated_TTP') - if not indicator_dict.get('confidence', True): - list_missing.append('Confidence') - - print ' [~] id: [%s] line: [%s] missing: %s' % (indicator_dict.get('id'), node.sourceline, list_missing) + node = indicator_dict['node'] + print ' [~] id: [%s] line: [%s] missing: %s' % (indicator_dict.get('id'), node.sourceline, indicator_dict.get('missing')) else: print "[!] %s : INVALID : [%s]" % (fp, str(validation_error)) diff --git a/stix_validator/validator.py b/stix_validator/validator.py index 6059505..a75f6b2 100755 --- a/stix_validator/validator.py +++ b/stix_validator/validator.py @@ -173,6 +173,16 @@ def __init__(self, schema_dir=None, use_schemaloc=False, best_practices=False): self.best_practices = best_practices def _check_id_presence_and_format(self, instance_doc): + '''Checks that the core STIX/CybOX constructs in the STIX instance document + have ids and that each id is formatted as [ns_prefix]:[object-type]-[GUID]. + + Returns a dictionary of lists. Each dictionary has the following keys: + no_id - a list of etree Element objects for all nodes without ids + format - a list of etree Element objects with ids not formatted as [ns_prefix]:[object-type]-[GUID] + + Keyword Arguments + instance_doc - an etree Element object for a STIX instance document + ''' return_dict = {'no_id' : [], 'format' : []} @@ -203,6 +213,15 @@ def _check_id_presence_and_format(self, instance_doc): return return_dict def _check_duplicate_ids(self, instance_doc): + '''Looks for duplicate ids in a STIX instance document. + + Returns a dictionary of lists. Each dictionary uses the offending + id as a key, which points to a list of etree Element nodes which + use that id. + + Keyword Arguments + instance_doc - an etree.Element object for a STIX instance document + ''' dict_id_nodes = defaultdict(list) dup_dict = {} xpath_all_nodes_with_ids = "//*[@id]" @@ -218,6 +237,12 @@ def _check_duplicate_ids(self, instance_doc): return dup_dict def _check_idref_resolution(self, instance_doc): + '''Checks that all idref attributes in the input document resolve to a local element. + Returns a list etree.Element nodes with unresolveable idrefs. + + Keyword Arguments + instance_doc - an etree.Element object for a STIX instance document + ''' list_unresolved_ids = [] xpath_all_idrefs = "//*[@idref]" xpath_all_ids = "//@id" @@ -232,6 +257,12 @@ def _check_idref_resolution(self, instance_doc): return list_unresolved_ids def _check_idref_with_content(self, instance_doc): + '''Looks for elements that have an idref attribute set, but also have content. + Returns a list of etree.Element nodes. + + Keyword Arguments: + instance_doc - an etree.Element object for a STIX instance document + ''' list_nodes = [] xpath = "//*[@idref]" nodes = instance_doc.xpath(xpath) @@ -243,25 +274,36 @@ def _check_idref_with_content(self, instance_doc): return list_nodes def _check_indicator_practices(self, instance_doc): + '''Looks for STIX Indicators that are missing a Title, Description, Type, Valid_Time_Position, + Indicated_TTP, and/or Confidence + + Returns a list of dictionaries. Each dictionary has the following keys: + id - the id of the indicator + node - the etree.Element object for the indicator + missing - a list of constructs missing from the indicator + + Keyword Arguments + instance_doc - etree Element for a STIX instance document + ''' list_indicators = [] xpath = "//%s:Indicator | %s:Indicator" % (self.PREFIX_STIX_CORE, self.PREFIX_STIX_INDICATOR) nodes = instance_doc.xpath(xpath, namespaces=self.NS_MAP) for node in nodes: - dict_indicator = {} + dict_indicator = defaultdict(list) if not node.attrib.get('idref'): # if this is not an idref node, look at its content if node.find('{%s}Title' % (self.NS_STIX_INDICATOR)) is None: - dict_indicator['title'] = False + dict_indicator['missing'].append('Title') if node.find('{%s}Description' % (self.NS_STIX_INDICATOR)) is None: - dict_indicator['description'] = False + dict_indicator['missing'].append('Description') if node.find('{%s}Type' % (self.NS_STIX_INDICATOR)) is None: - dict_indicator['type'] = False + dict_indicator['missing'].append('Type') if node.find('{%s}Valid_Time_Position' % (self.NS_STIX_INDICATOR)) is None: - dict_indicator['valid_time_position'] = False + dict_indicator['missing'].append('Valid_Time_Position') if node.find('{%s}Indicated_TTP' % (self.NS_STIX_INDICATOR)) is None: - dict_indicator['indicated_ttp'] = False + dict_indicator['missing'].append('TTP') if node.find('{%s}Confidence' % (self.NS_STIX_INDICATOR)) is None: - dict_indicator['confidence'] = False + dict_indicator['missing'].append('Confidence') if dict_indicator: dict_indicator['id'] = node.attrib.get('id') @@ -271,6 +313,20 @@ def _check_indicator_practices(self, instance_doc): return list_indicators def check_best_practices(self, instance_doc): + '''Checks that a STIX instance document is following best practice guidance. + + Looks for the following: + + idrefs that do not resolve locally + + elements with duplicate ids + + elements without ids + + elements with ids not formatted as [ns_prefix]:[object-type]-[GUID] + + indicators missing a Title, Description, Type, Valid_Time_Position, Indicated_TTP, and/or Confidence + + Returns a dictionary of lists and other dictionaries. This is maybe not ideal but workable. + + Keyword Arguments + instance_doc - a file-like object for a STIX instance document + ''' instance_doc.seek(0) tree = et.parse(instance_doc) root = tree.getroot() From 9d59ce123e7e703624389058f55b37799906cf2e Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Thu, 12 Sep 2013 15:17:37 -0400 Subject: [PATCH 10/14] Update README.md --- stix_validator/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/stix_validator/README.md b/stix_validator/README.md index ae16e24..c68a850 100644 --- a/stix_validator/README.md +++ b/stix_validator/README.md @@ -27,7 +27,7 @@ Validate a directory of STIX documents: `python sdv.py --input-dir --schema-dir schema` Check 'best practice' guidance -`python sdv.py --input-file --best-practices` +`python sdv.py --input-file --schema-dir schema --best-practices` ## All STIX Documents? The STIX Document Validator bundles a schema directory with it, which includes all STIX v1.0 From 46b0fbb8e9f6107af05db5ddda6e1496cc3177b7 Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Thu, 12 Sep 2013 16:07:20 -0400 Subject: [PATCH 11/14] fixed issue where parsing exceptions result in stack traces --- stix_validator/validator.py | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/stix_validator/validator.py b/stix_validator/validator.py index a75f6b2..e19cde0 100755 --- a/stix_validator/validator.py +++ b/stix_validator/validator.py @@ -124,9 +124,12 @@ def validate(self, instance_doc): if not(self.__use_schemaloc or self.__imports): return (False, "No schemas to validate against! Try instantiating XmlValidator with use_schemaloc=True or setting the schema_dir") - instance_doc = et.parse(instance_doc) - instance_root = instance_doc.getroot() + try: + instance_doc = et.parse(instance_doc) + except et.XMLSyntaxError as e: + return (False, str(e)) + instance_root = instance_doc.getroot() if self.__use_schemaloc: try: required_imports = self._extract_schema_locations(instance_root) From ebb7b2f44cfce8dbdd8655e55a5b2d0da83a4d19 Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Thu, 12 Sep 2013 16:08:05 -0400 Subject: [PATCH 12/14] changed os.walk() to os.listdir() for when --input-dir is used, fixing directory traversal behavior --- stix_validator/sdv.py | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/stix_validator/sdv.py b/stix_validator/sdv.py index d6bd7fc..06c3490 100755 --- a/stix_validator/sdv.py +++ b/stix_validator/sdv.py @@ -13,11 +13,10 @@ def get_files_to_validate(dir): '''Return a list of xml files under a directory''' to_validate = [] - for top, dirs, files in os.walk(dir): - for fn in files: - if fn.endswith('.xml'): - fp = os.path.join(top, fn) - to_validate.append(fp) + for fn in os.listdir(dir): + if fn.endswith('.xml'): + fp = os.path.join(dir, fn) + to_validate.append(fp) return to_validate From 8625b1f702cfd7dc5782a89bcba7b3125cce4f2e Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Thu, 12 Sep 2013 16:19:49 -0400 Subject: [PATCH 13/14] added best practice validator method that checks if root element is STIX_Package --- stix_validator/validator.py | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/stix_validator/validator.py b/stix_validator/validator.py index e19cde0..ea6eb56 100755 --- a/stix_validator/validator.py +++ b/stix_validator/validator.py @@ -315,6 +315,13 @@ def _check_indicator_practices(self, instance_doc): return list_indicators + def _check_root_element(self, instance_doc): + if instance_doc.tag != "{%s}STIX_Package" % (self.NS_STIX_CORE): + return instance_doc + else: + return None + + def check_best_practices(self, instance_doc): '''Checks that a STIX instance document is following best practice guidance. @@ -334,13 +341,15 @@ def check_best_practices(self, instance_doc): tree = et.parse(instance_doc) root = tree.getroot() + root_element = self._check_root_element(root) list_unresolved_idrefs = self._check_idref_resolution(root) dict_duplicate_ids = self._check_duplicate_ids(root) dict_presence_and_format = self._check_id_presence_and_format(root) list_idref_with_content = self._check_idref_with_content(root) list_indicators = self._check_indicator_practices(root) - return {'unresolved_idrefs' : list_unresolved_idrefs, + return {'root_element' : root_element, + 'unresolved_idrefs' : list_unresolved_idrefs, 'duplicate_ids' : dict_duplicate_ids, 'missing_ids' : dict_presence_and_format['no_id'], 'id_format' : dict_presence_and_format['format'], From a8c1ae6f869cf757edfd7acb8ff1ab6fc96d4900 Mon Sep 17 00:00:00 2001 From: Bryan Worrell Date: Thu, 12 Sep 2013 16:20:15 -0400 Subject: [PATCH 14/14] modified output of sdv.py --- stix_validator/sdv.py | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-) diff --git a/stix_validator/sdv.py b/stix_validator/sdv.py index 06c3490..523dc5a 100755 --- a/stix_validator/sdv.py +++ b/stix_validator/sdv.py @@ -30,46 +30,45 @@ def print_result(fp, isvalid, validation_error, warnings): print "[+] %s : VALID" % (fp) if warnings: + root_element = warnings.get('root_element') + if root_element is not None: + print ' [#] Root element not STIX_Package: [%s]' % (root_element.tag) + duplicate_ids = warnings.get('duplicate_ids') if duplicate_ids: - print ' [~] Nodes with duplicate ids' + print ' [#] Nodes with duplicate ids' for id_, list_nodes in duplicate_ids.iteritems(): print ' [~] id: [%s]' % (id_) for node in list_nodes: print ' [%s] line: [%s]' % (node.tag, node.sourceline) - print - + missing_ids = warnings.get('missing_ids') if missing_ids: - print ' [~] Nodes with missing ids' + print ' [#] Nodes with missing ids' for node in missing_ids: print ' [~] [%s] line: [%s]' % (node.tag, node.sourceline) - print - + unresolved_idrefs = warnings.get('unresolved_idrefs') if unresolved_idrefs: - print ' [~] Nodes with idrefs that do not resolve' + print ' [#] Nodes with idrefs that do not resolve' for node in unresolved_idrefs: print ' [~] [%s] idref: [%s] line: [%s]' % (node.tag, node.attrib.get('idref'), node.sourceline) - print - + formatted_ids = warnings.get('id_format') if formatted_ids: - print ' [~] Nodes with ids not formatted as [ns_prefix]:[object-type]-[GUID]' + print ' [#] Nodes with ids not formatted as [ns_prefix]:[object-type]-[GUID]' for node in formatted_ids: print ' [~] [%s] id: [%s] line: [%s]' % (node.tag, node.attrib.get('id'), node.sourceline) - print - + idrefs_with_content = warnings.get('idref_with_content') if idrefs_with_content: - print ' [~] Nodes that declare idrefs but also contain content' + print ' [#] Nodes that declare idrefs but also contain content' for node in idrefs_with_content: print ' [~] [%s] idref: [%s] line: [%s]' % (node.tag, node.attrib.get('idref'), node.sourceline) - print indicator_suggestions = warnings.get('indicator_suggestions') if indicator_suggestions: - print ' [~] Indicator suggestions' + print ' [#] Indicator suggestions' for indicator_dict in indicator_suggestions: node = indicator_dict['node'] print ' [~] id: [%s] line: [%s] missing: %s' % (indicator_dict.get('id'), node.sourceline, indicator_dict.get('missing'))