3 PremiseBuilding secure systems and effectively responding to incidents requires an understanding of the relevant threatsAn actionable understanding of today’s scale, complexity and volume of relevant threats requires structured representations to support automationThreat informationAttacker motivationAttacker behavior (TTP)Attacker capabilityTargeted attack surfacePotential impactHow to detect threatHow to mitigate threatSolution ResourcesCommon Attack Pattern Enumeration and Classification (CAPEC) for structured characterization of attack patternsMalware Attribute Enumeration and Characterization (MAEC) language for structured characterization of malwareCyber Observable eXpression (CybOX) underpinning CAPEC & MAEC
4 The Long-established Principal of “Know Your Enemy” “One who knows the enemy and knows himself will not be endangered in a hundred engagements. One who does not know the enemy but knows himself will sometimes be victorious. Sometimes meet with defeat. One who knows neither the enemy nor himself will invariably be defeated in every engagement.”Chapter 3: “Planning the Attack”The Art of War, Sun TzuAn appropriate defense can only be established if you know how it will be attacked
5 What are Attack Patterns? Blueprint for creating a specific type of attackAbstracted common attack approaches from the set of known exploitsCapture the attacker’s perspective to aid software developers, acquirers and operators in improving the assurance profile of their systems
6 Leveraging Attack Patterns Throughout the Software Lifecycle Guide definition of appropriate policiesGuide creation of appropriate security requirements (positive and negative)Provide context for architectural risk analysisGuide risk-driven secure code reviewProvide context for appropriate security testingIdentify and characterize threat TTPs for red teamingProvide a bridge between secure development and secure operationsIdentify patterns of malicious behavior for attack detection and characterization in operations
7 Common Attack Pattern Enumeration and Classification (CAPEC) Community effort targeted at:Standardizing the capture and description of attack patternsCollecting known attack patterns into an integrated enumeration that can be consistently and effectively leveraged by the communityGives you an attacker’s perspective you may not have on your ownExcellent resource for many key activitiesAbuse Case developmentArchitecture attack resistance analysisRisk-based security/Red team penetration testingWhitebox and Blackbox testing correlationOperational observation and correlationWhere is CAPEC today?Currently 386 patterns, stubs, named attacks68 Categories & 6 Views
11 Attack Patterns Bridge Secure Development and Operations Secure OperationsAttack Patterns
12 Secure Operations Knowledge Offers Unique Value to Secure Development Using attack patterns makes it possible for the secure development domain to leverage significant value from secure operations knowledge, enabling them to:Understand the real-world frequency and success of various types of attacks.Identify and prioritize relevant attack patterns.Identify and prioritize the most critical weaknesses to avoid.Identify new patterns and variations of attack.Secure Development Knowledge Offers Unique Value to Secure OperationsAttack patterns enable those in the secure operations domain to provide appropriate context to the massive amounts of data analyzed to help answer the foundational secure operations questions.
13 Cyber Observables Overview The Cyber Observables construct is intended to capture and characterize events or properties that are observable in the operational domain.These observable events or properties can be used to adorn the appropriate portions of the attack patterns in order to tie the logical pattern constructs to real-world evidence of their occurrence or presence.This construct has the potential for being the most important bridge between the two domains, as it enables the alignment of the low-level aggregate mapping of observables that occurs in the operations domain to the higher-level abstractions of attacker methodology, motivation, and capability that exist in the development domain.By capturing them in a structured fashion, the intent is to enable future potential for detailed automatable mapping and analysis heuristics.
22 Current Maturation Paths Extend coverage of CAPECImprove quality of CAPECExpand the scope of CAPECBridge secure development with secure operationsImprove integration with other standards (MAEC, CEE, etc.)Expand use of CAPECEstablish initial compatibility program
24 Why Do We Need to Develop Standards for Malware? Lots of productsMultiple layers of protectionInconsistent reportsThere’s an arms race
25 Malware Attribute Enumeration and Characterization (MAEC) Language for sharing structured information about malwareGrammar (Schema)Vocabulary (Enumerations)Collection Format (Bundle)Focus on attributes and behaviorsEnable correlation, integration, and automationThreatsVulnerabilitiesDetectionResponsePlatforms
26 MAEC Use Cases Operational Analysis Help Guide Analysis Process Standardized Tool OutputMalware RepositoriesToolTool
27 MAEC OverviewIn terms of structure, MAEC can be thought of as having three interconnected layers: At the lowest level, which serve to answer the question of ‘what’ the malware does through ‘actions’, which serve to characterize hardware accesses and system state changes performed by malware. Thus, actions can be relatively amorphous, although initially we have concentrated on defining those that can be achieved through low-level API calls. However, the main point with regards to actions is that they are relatively devoid of any significant meaning – they don’t answer the question of ‘why’ the malware performed them in the first place.What we are attempting to show the division between semantics and syntactics is that we are abstracting actions away from their implementations. Such abstract actions will allow the construction of a more concise grammar, and also facilitate correlation between malware that may do similar things at a low-level but with vastly different implementations (such as malware targeted at different platforms). Of course, this doesn’t mean that we should throw out how an action is implemented, as this is certainly useful for purposes of correlation, as the same action can have many possible implementations.The more interesting structure of MAEC begins at the mid-level, which we term ‘Behaviors.’ Behaviors are aimed at organizing and defining the purpose behind low-level actions, whether in groups or as singletons. Thus, Behaviors can represent discrete components of malware functionality at a level that is useful for analysis, triage, detection, etc.Going up another level, we have what we refer to as Mechanisms. Mechanisms are organized groups of behaviors. Some examples would be propagation/insertion, self-defense, and the like. Since there is likely a very low upper bound on the number of possible mechanisms, they can be useful in terms of understanding the composition of malware at a very high level.As a very simple example of how a malicious action can be mapped between MAEC’s levels, let’s say that some malware calls Windows’ CreateFile() API Call and creates xyz.dll. This would first be mapped to the Create File action; after further investigation, we conclude that this file was created as a means of instantiating a malicious binary on a system, thus mapping to a MAEC Behavior in this fashion. Finally, Malicious Binary Instantiation can be considered as part of a malware persistence mechanism.Transition: For the initial MAEC release, we’ve been focusing primarily on actions, particularly with regards to those that can be characterized through dynamic analysis engines and sandboxes. Thus, let me go into a bit more detail with regards to our action model.
28 MAEC Description: Profiling Zeus C2 MAEC Mechanism: C2MAEC Behavior: C2 Get ConfigurationMAEC Behavior: C2 BeaconMAEC Behavior: C2 Receive CommandMAEC Behavior: C2 Send Data
35 Use Case: Host Based Detection Dynamic Analysis EngineAnubisCWSandboxThreatExpertEtc.Engine OutputSandbox -> MAEC TranslatorMalware BinaryHost-based Scanner
36 Real World Example: MAEC & Zeus Bot OVAL OutputAnubis Output*Anubis MAEC Translator ScriptMAEC OutputAnubis SandboxZeus BinaryMAEC OVAL Translator Script*http://anubis.iseclab.org/?action=result&task_id=1167a57d1aa905e949df5d5478ab23bf9
37 Use Case: Data Fusion & Correlation DNS/WhoisPCAPRev EngThreat Reports…Is this malware similar to recent activity?Decompose QuestionActivityTemporalRecent=1wkBehaviorC2BeaconReceiveExploitDownloadOntologiesQuery Inference EngineMalware BinaryZeus XZeus YExtract Features
38 v2.0 Changes MAEC object model replaced with CybOX ActionType simplifiedEffectType refined, made easier to useMore object-focusedPermits definition of much more complex effectsLots of ‘under the hood’ tweaks and minor additionsMAEC Bundle now supports storage of Objects, Actions, Behaviors, and Analyses at the top levelAdditional analysis environment attributes added to Analysis TypeEnumerations made into separate typesMain entities streamlined to remove unnecessary hierarchyMany more
39 v2.0 Additions v Signature/Indicator Management Capability Permits standard method of defining anti-malware signatures and indicators. Examples: OpenIOCs, ClamAV, Yara, Snort, etc.Linkages to other MAEC entities where appropriate. E.g. objects for specifying signature/indicator used in detection.Relationship SupportAllows defining simple relationships between MAEC entities in an easy to use fashion. Examples: ParentOf, ChildOf, PrecededBy, etc.Many new enumerated typesActions, Effects, Relationships, etc.
41 MAEC v2.0 Objects (imported from CybOX) AccountDiskDisk PartitionDNS CacheMessageFileGUILibraryPackageMemoryNetwork ConnectionNetwork RouteLinux PackageProductServiceSocketSystemUser SessionVolumeWin Critical SectionWin DriverWin EventWin Event LogWin KernelWin Kernel HookWin HandleWin MailslotWin MutexWin Named PipeWin Network RouteWin PrefetchWin RegistryWin SemaphoreWin System RestoreWin TaskWin ThreadWin Waitable TimerX509 Certificate…(more on the way)
42 MAEC & CybOX MAEC MAEC CybOX Before (MAEC 1.x) After (MAEC 2.0 and up) MAEC EntitiesMAEC ObjectsAfter (MAEC 2.0 and up)MAECCybOXDefined ObjectDefined ObjectMAEC EntitiesDefined Object TypeDefined ObjectObject TypeImportsSubstitutes
43 Community Engagement Industry Collaborations Working with Mandiant on MAEC <-> openIOCTool vendors supported our development of MAEC translators:CWSandbox : GFI SoftwareThreatExpert : SymantecAnubis : International Secure Systems (Isec) LabDiscussions with tool vendors about adopting MAEC as a native output format (under NDAs)Malware analysts experimenting with MAEC (e.g., to compare multiple tool output)
44 Community Engagement IEEE Industry Connections Security Group (ICSG) Malware Working Group developed an exchange schema to facilitate the sharing of sample data between AV product vendorsMAEC currently imports the IEEE ICSG Malware Metadata exchange schemaRecently established Malware Metadata Exchange Format WGMain Focus:Adding capability to MMDEF schema for capturing blackbox behavioral metadata about malwareWill likely import MAEC/CybOX, especially MAEC Objects and ActionsSecondary Focus:Adding capability to MMDEF schema for profiling clean (non-malicious) files, including software packagesAimed at sharing information about clean files for reducing AV detection false positivesPotentially transition to a new IEEE standard
45 MAEC Community: Discussion List Request to join:Archives available
46 MAEC Community: MAEC Development Group on Handshake MITRE hosts a social networking collaboration environment: https://handshake.mitre.orgSupplement to mailing list to facilitate collaborative schema developmentMalware Ontologies SIG Subgroup