STIX Profile Development Tutorial

Transcription

1 STIX Profile Development Tutorial This tutorial describes how to create a STIX Profile step-by-step, with a particular focus on creating community profiles using the profile spreadsheet format with the Excel template. The tutorial will walk through the creation process and give both general directions as well as follow an example through. The end result of following the tutorial will be the sample indicator profile. You should be familiar with both STIX and STIX profiles before following this tutorial, so if you haven't already you should read the Profile Overview Whitepaper. Version: 0.1 (DRAFT) Getting Started: What type of profile should I create? The first step to creating a profile is to understand which type of profile you want to create. In general, profiles can be bucketed into a few types, and by understanding the type of profile you want to create you can ask yourself the right questions about what to include. For the example in this document, we'll be creating a community profile that will allow a number of organizations to exchange basic indicator information. Community Profiles Community profiles describe how a particular sharing community (an industry collaboration group, a government sharing program, etc.) will use STIX. In these types of profiles, you have many parties involved in both producing and consuming information. Community profiles can also be created outside the context of any particular sharing program to help standardize practices across the entire industry. These profiles should be developed with participation from most or all members of the community to ensure that they aren't too focused on any one technical implementation or one organization's biases. The community should, together, discuss the items in the "What does my profile need to consider?" section and arrive at an agreement. For community profiles, you should consider whether fields will be required, suggested, optional, or prohibited: Required: All STIX documents must include this element to conform to the profile. This should be used only if all community members agree that they can and should populate this field for all content. Suggested: STIX documents should include this element to conform to the profile. This can be used for fields that the community thinks are very useful but may not be available all of the time.

2 Optional: STIX documents may include this element and conform to the profile. This can be used for fields that are useful in some, but not all, situations or for some, but not all, community members. Prohibited: STIX documents must not include this element to conform to the profile. This should be used for all fields that the community feels are not useful. The major advantage of marking fields as prohibited is that developers can assume that the fields will not be present and do not have to develop to them. A field can either be explicitly marked as prohibited or, if it is not marked as required, suggested, or optional, it is implicitly considered prohibited. Producer Profiles Producer profiles describe how one particular producer will be creating STIX documents. This is useful for tool developers, commercial threat intelligence feeds, and sharing programs where a single producer is publishing to many consumers. The use of a profile in this case makes it easier for consumers to implement only the portion of STIX that is actually used. It can also help consumers understand the type of information that they producer will be publishing in order to decide whether the feed is worth consuming at all. Producer profiles can be compared to community profiles to determine whether the producer is compliant with any given community profile. Using the profile layering concept outlined in the profile whitepaper, a producer profile is compatible with a community profile if it is a complete subset (child) of that profile. For producer profiles, the producer itself should develop the profile in order to ensure that it is accurate. She should consider whether fields will always be present, might be present, or will never be present: Required (Always Present): Fields that will always be present are marked as required in order to line up with the language community profiles use. These fields will always be populated in all documents the producer publishes. Optional (Sometimes Present): Fields that will sometimes be present are marked as optional to line up with the language community profiles use. These fields might be present in documents the producer publishes. Prohibited (Never Present): Fields that will never be present are marked as prohibited to line up with the language community profiles use. These fields will not be present in documents the producer publishes. Consumer Profiles Consumer profiles are essentially compatibility statements: a consumer can create them to demonstrate which portions of STIX they support. They can then be compared to community or producer profiles to determine whether the consumer is compatible. If a consumer profile is a parent (superset) of either a producer or community profile it can be considered fully compatible. In other cases, it may be a partial superset/subset but have support for

3 ignoring fields it does not handle rather than throwing an error, in which case it can be considered partially compatible. For consumer profiles, the consumer should develop the profile to ensure that it is accurate. They should consider whether fields are required, supported, not supported, or will throw an error: Required: Fields that MUST be present in a STIX document for this consumer to consume the document without errors. For consumer profiles, this should likely only be ID or other very basic elements. Supported: Fields that MAY be present in a STIX document and that will be properly handled. Not Supported: Fields that MAY be present in a STIX document but that will not be properly handled. Error: Fields that will cause the consumer to throw an error if present. The rest of this guide will discuss the creation of community profiles. Producer and consumer profiles can follow much of the same process, with the caveats that they should bucket fields as described in the appropriate section above. Populating the high level overview Regardless of the type of profile that is chosen, several high-level decisions must be made before going into field-level details. In the profile template, these decisions are documented on the "Overview" tab. Populate all metadata 1. Name 2. Status (Draft, Final, etc) 3. Version 4. Contact s 5. Date Published 6. Distribution (Public, Proprietary, etc) 7. Description For this example, we'll use: 1. Name: "Sample Indicator Sharing Profile Simple Static Publish" 2. Status (Draft, Final, etc): "SAMPLE" 3. Version: "0.1" 4. Contact s: "The MITRE Corporation (stix@mitre.org)" 5. Date Published: "8 July 2013" 6. Distribution (Public, Proprietary, etc): "Public" 7. Description: <See sample>

4 Document which STIX Components and CybOX Objects you want to include The community should discuss which top-level objects they want to include at a very high level. During later steps you will tune which particular fields in STIX components you will be using, but for the time being just mark each component as "permitted" if you plan to use it or "prohibited" if you don't. Similar to STIX Components, the community should determine which CybOX objects they want to include at a high level. These will also be tuned later in the process, so for now just mark them as "permitted" or "prohibited". If you don't plan to use CybOX (you marked "Observables" as prohibited in the STIX Components) you should mark them all as prohibited. In this example, we're developing a profile to share basic indicator information. So, we'll want to include Indicator and Observable in order to share the indicators themselves. In addition, we want to share some context for the Indicator as well as potential courses of action and so will also permit TTP and Course of Action. Incident, Exploit Target, Threat Actor, and Campaign are all marked as prohibited because they will not be used for this simple incident sharing use case. For CybOX objects, we select a set that allows us to express common network and host-based indicators: Address, Artifact, DNS Query, DNS Record, Message, File, HTTP Session, Link, Mutex, Network Connection, Network Flow, Network Packet, Port, Socket Address, URI, Win Registry Key. All other objects are marked as prohibited so that consumers understand that they don't have to implement them. Document which STIX Extensions you want to use For each STIX Extension you will need to determine whether your community wants to support it or not. In many cases, you can mark all extensions of a certain type as prohibited. For example, if you don't intend to support test mechanisms in a certain profile you can mark all test mechanism extensions as prohibited. In other cases, you might wish to support only a single extension of a given type so that consumers and producers only have to implement one option. For example, it's useful to agree upon a single data marking (handling) format so that producers and consumers only need to support one and can unambiguously mark data. So you might mark TLP as permitted and Simple Marking as prohibited. If you have any third-party extensions, you should add a cell for them and mark them appropriately. In this example we will support TLP to do data handling but will mark all other extensions as prohibited. Simple marking is prohibited because we want producers and consumers to all only have to support and use TLP and all other extensions are prohibited because we don't plan to support any extensions of those types. Document which STIX and CybOX Features you want to use For each STIX and CybOX feature, determine whether your community wants to support it: STIX Handling: Data marking and handling

5 Confidence: Confidence assertions Relationships: Relationships between STIX components Markup in Structured Text: The use of markup in structured text content CybOX Object: The use of CybOX objects (almost always permitted if you're using CybOX) Event: The use of CybOX events Relationships: Relationships between CybOX objects, events, and actions If you're not using CybOX, all CybOX features should be marked as prohibited. In this example, we permit STIX Handling, Confidence, and Relationships but prohibit STIX Markup in Structured Text. We also allow CybOX Objects and Relationships but prohibit events. Vocabularies For now, leave all the vocabularies as-is. After selecting which fields to include, we can come back and mark the vocabularies used for those fields. If you have any custom vocabularies, however, you can add cells for them now. Preparing the Spreadsheet Note: this section is only applicable to the spreadsheet format when starting with the template. When working from the template, the next step is to prepare the template by: 1. Removing any tabs that are not used. 2. Adding any tabs for CybOX objects if you want to go into that level of detail. You can also leave these tabs off, which means that all fields in the objects are optional. For our example, we remove the tabs for Incident, Exploit Target, Threat Actor, and Campaign because they are not used at all. We could also add tabs for each of the CybOX objects we marked as permitted in order to further refine how those objects are used, but in order to keep this tutorial and sample short we will not in this case. That means that in the indicator profile sample, all fields in the marked CybOX objects are optional. Filling out the fields for each type The most important step in creating the profile is filling out the fields in each schema (tab on the spreadsheet). Starting with STIXType in the second tab (STIX Package) and working your way through all types on all tabs, follow the following process for each type (marked in black headings): 1. Iterate through each field in the type, marking it up appropriately:

6 a. Code the field as required, suggested, optional, or prohibited by changing the background color of the row appropriately per the legend on the overview tab. b. If the field uses a controlled vocabulary (has a type of ControlledVocabularyStringType) mark which vocabulary you want to use in the Restrictions column. Often this will be the default vocabulary for that field, which you can find in the schema, data dictionary, or documentation. c. If a field uses an extension or an implementation through xsi:type, indicate the expected implementation(s) in the Restrictions column. d. If the type is a simple value and you want to limit the possible values that can appear in the field, indicate that in the Restrictions column. e. Enter any additional notes or clarifications in the Notes column 2. Look at all the fields in the type you just finished that are required, suggested or optional (anything that is not prohibited) and that are not simple types like xs:string. The types for these fields (usually in the second column) all need to be coded by following step 1 for that type. As you work through the spreadsheet, you should notice that in many cases the type is already coded because it was used in a previous field and you can skip it. 3. In many cases fields will be used through xsi:type extension points. Although these types will not be listed in the second column where they are used, they also need to be coded. Most often this is the case for CybOX Objects, STIX Extensions, and STIX Components. 4. Types that are not used anywhere else (remain un-coded by the end of the document) can simply be hidden or removed because they are completely prohibited. With experience you might be able to take shortcuts by hiding or removing unused types from the start, but when first starting out it's safer to wait and see if they're actually used before removing them. Note that there are also some special cases that are not noted on the flowchart: Sometimes, a type is used in one place and you want to use it in one way (with certain fields required, suggested, optional or prohibited) while if a type is used in another place you want it used differently. If that happens, you can copy the entire type itself and rename the top heading from just the type name ("stixcommon:identitytype") to something reflective of how it's used ("stixcommon:identitytype as used by InformationSource"). There may be some components (like CybOX objects in our example) that you don't want to individually code. If that's the case, you can assume that all fields are "Optional" in that type and not include it. Note: You should be clear you have taken this approach in the places that type is used elsewhere in the profile.

7 Filling out the fields (example) Following our example and the flowchart above, we would start with the type stix:stixtype. Then, looking at the first field in that type (STIX_Header) we would code it appropriately. In this case, STIX_Header will be suggested but not required. Moving to the next item, the "Observables" element will be optional, because while you'll need to include observables to do indicator sharing you could always embed them in the indicator itself. Because this is an indicator sharing profile and that would not make much sense without including indicators, the Indicators element is marked suggested. The same process continues through each of the fields in STIXType: Exploit_Targets, Incidents, Campaigns, Threat_Actors, are marked are marked suggested. TTPs and Courses of Action are marked optional.

8 Then, following the flow chart above, we would start at the top again and walk through all items marked required, suggested, or optional. In this case, we start with STIX_Header because it is marked as "Suggested". Finding the type in the second column (STIXHeaderType) we go to that section in the spreadsheet and code STIXHeaderType appropriately: Title is marked suggested Package_Intent is marked suggested and we note in the "Restrictions" column that it uses the PackageIntentVocab-1.0 The rest of the elements are marked optional. Again, following the flowchart above, we start at the top of STIX_Header and look for types that need to be coded. Title is a simple type so we can skip that, while Package_Intent is not a simple type and must be coded. So we go to the STIX Common tab (where that ControlledVocabularyStringType is defined) and code it. Following the flowchart, there are no non-simple, non-coded types in ControlledVocabularyStringType so we go up a level and continue with STIX_Header. This process continues until we're done with the spreadsheet. Then, we decide if we want to code any CybOX objects. If we do, we would copy that worksheet over from the CybOX Objects template and begin the process again. Finally, once we've completely coded every type that is used we can remove the types that are not used by deleting all of the rows for that type. Set the vocabularies and verify the overview tab Based on the fields that you selected as required, suggested, or optional and the implementations (vocabularies) you selected in the third column, code the list of vocabularies on the overview tab as "Permitted" or "Prohibited". Similarly, verify that the features, components, extensions, and CybOX objects are all correct. In the walkthrough above for STIX_Header/Package_Intent, we noticed that that field uses a controlled vocabulary with a default vocab of PackageIntentVocab-1.0. Because we marked that as the implementation for the Package_Intent field, we mark it as permitted in the overview. While we didn't go over HighMediumLowVocab-1.0 and the rest of the included vocabularies in this tutorial, if you look at the sample you'll notice that the vocabularies are all used by fields on later tabs so they are marked as permitted as well. Cleanup/Consolidate You may wish to clean up or consolidate the list of tabs in the profile spreadsheet. Sometimes, for example, it's useful to consolidate "STIX Package" and "STIX Common" into a single sheet called "STIX Package". This is purely cosmetic but keeps the profile from having too many tabs. On our sample spreadsheet we consolidated items from STIX Package, STIX Common, and Data Marking onto the sheet called STIX Package.