Presentation on theme: "Operational Cyber Threat Intelligence:"— Presentation transcript:
1Operational Cyber Threat Intelligence: 3 Years of IOC Processing at EMCChris Harrington Cyber Threat Intelligence / Advanced Tools Lead EMC Critical Incident Response Center Kathleen Moriarty Security Area Director, IETF and Global Lead Security Architect EMC Corporate CTO Office
2Agenda Lessons learned from 3+ years @ EMC Efficient and Effective Information ExchangesTransport Options for Data ExchangesIETF Update, transforming securityHow can I participate in the IETF?End Users, Developers, Implementers, Vendors, etc.
3EMC CIRC Critical Incident Response Center Staffed 24x7 Locations in Massachusetts and Bangalore25 full time employees split across 5 teamsCIRTCATATTACTISecurity Sciences
4Incident Response @ EMC 50,000 Employees20,000+ contractors500+ locations in over 80 countries8 Internet gateways250,000+ endpointsNever a shortage of “interesting” things
5Flashback to March, 2011 RSA had a security issue You may have heard about it CIRC was fewer than 10 people, not 24x7Post- breach analysis indicated that “Threat Intelligence would have played a major role in detecting this activity.”
6So what did we do? Built a full time CyberThreat Intelligence group 2.5 FTE’sBought multiple intelligence feedsJoined multiple threat sharing groupsCustom developed a Threat Intel portal / DBDeveloped own in house OSINT gathering
8Observed Threat Intel Issues Some Threat Intel vendors don’t understand the difference, Intelligence vs. Information.Here is a “bad” IP with no context as to why it’s badNeeds to be actionable to be IntelligenceResult: Resources wasted on false positivesResult: Resources wasted researching
9Observed Threat Intel Issues Lack of widely adopted standard for sharing Threat Intelligence or IoCsSTIX, IODEF, OpenIOC all have Limited vendor adoptionResult: Resources wasted on logging into various portals, maliling lists, feeds, etc.Result: Human errors when transferring data
10Observed Threat Intel Issues Limited platforms / applications for Threat IntelSharing, reviewing / approving, integration, “retiring”Have you every retired an IoC?How big are your block lists?Result: IoC lifecycle management very difficult.Result: Increased impact on security controls
11Observed Threat Intel Issues Quality of product from vendors variesSome do a good job of vetting indicatorsHowever we still see listed as badResult: Impact to operationsI blocked Salesforce.com for 30 minutes Result: Custom tools to vett intelligence / IoCs
12Observed Threat Intel Issues Justifying the expense to managementLack of obvious “wins”Early failures due to poor 3rd party intelligenceStill not finding “all the bad stuff”A lot of custom development
13What did we do? Reviewed Threat Intel sources Removed those that fail to provide contextTaking a hard look at those who don’t provide structured IoC delivery, regardless of contextUnderstand each vendors focus areas.Do you need Cybercrime Intel or just APT?Migrated from custom Portal to CRiTSStill requires substantial code changes to support EMC workflowDeveloping capability to integrate with multiple sharing standards
14What is next? Efficiency Tracking incident false positive rate based on Threat Intelligence sourceAssign confidence values to sourcesFeedback to source vendorCorrelating alerts across multiple data sources to add contextual elements to Incident recordWhen alert from DNS fires check proxy / firewall logs for contextual data and add to Incident
15What is next? Harvesting IoCs Malware Intelligence ProgramLeverages Yara, VirusTotal, Cuckoo, Internal DBSearch for new samples of specific Threat Actor tools each night and programmatically extract IoCsPassive DNSInternally generated and commercialUsed to pivot on known IoCs to find more
16Lessons Learned Threat Intel quality varies widely Get some samples before signing the contractAsk your peersThreat Intel requires manual data entryAmount is proportional to # of sourcesThis is improving, more support for standardsThreat Intel will likely require custom codingPortal/DB, workflow integration, federation/sharing
17Lessons Learned Organizational Maturity required Threat Intel isn’t the silver bulletNeed to manage expectationsExpensiveBoth in $$$ and human capitalRequires constant care and feedingNew vendor offerings, quality of dataDoesn’t always produce tangible resultsNo hits today. Intel failure or nothing going on?
19Pervasive Monitoring Call to Action: What kind of Internet does society want?Vulnerable to Attacks orSecure for all users?Bruce SchneierMy question to you: How will the FIRST community respond?
20Who is Sharing Data? What is Useful? Small & Medium OrganizationsDeploying security technologies with expectation of threat mitigationLarge OrganizationsParticipating in multiple sharing groupsReceiving multiple threat intelligence feedsAnalysis CenterAnalysis for industry focused or other sharing groupsNational CSIRTs providing information to government, critical infrastructure, etc.Internet Service Providers performing analysis, eliminating/mitigating threatsProblem specific analysis groups targeting focused threats (analysis & mitigation)Hidden from userIncreasingImpact Potential!Hidden & Exposed to UserUse case/user group specificEvolved by problem owner, may include multiple complimentary schemas or ones specific to the problem.IODEF/RIDARFeCrimeOpenIOCMalwareSTIXExtensionsEtc.
21Use Case Driven Adoption One Size Does Not Fit All Small & Medium OrganizationsLaw EnforcementLarge OrganizationsProprietaryOpenIOCVERISCSVCIFIODEF/ RIDSTIX/TAXIIVendorsConsortiums/ AlliancesOperatorsISACsShared threat intelligence must be:Directed: Intelligence received must be relevant to the organizationActionable: Intelligence must identify an immediate and active security response that mitigates the riskAutomated: Remediation based on intelligence must NOT impact the user experience
22Achieving Interoperability Rough Consensus and Running Code - InteroperabilitySimplicity“Complexity is the Enemy of Security”Options often eliminated to achieve interoperabilityRe-useDetermine requirements and evaluate appropriate solutionsUse existing protocols where appropriateReviewsFind problems that prevent interoperabilityWorking group experts in specific problem setArea specific reviews:Security, Transport, Routing, Application (internationalization, XML, etc.), General
23Transport Requirements Exchange of structured data formatsEnd-to-end encryptionAccess controlsPublish/subscribeFederationIntegration with existing toolsInteroperability between implementationsReduce options, ideally do what makes sense to meet requirementsConsider long term support and maintenance of specification or standard and open source implementationsAvailability of open source implementationsTransport should not be specific to a data formatFlexible for multiple types of connectionsPoint-to-pointMulti-point
24Transport Options Determine Best Fit Transport Option Protocol Intended UseProsConsRIDHTTP/TLSHigh-Security, Point-to-PointHigh-security level providedDoesn’t scale, protocol and design more appropriate for Point-to-pointTAXIIHTTP or HTTPS“Preferred transport for STIX” for all connections: Point-to-point, Hub-n-spoke, etc.Publish/subscribe supported through TAXII servicesLarge number of featuresComplex, plan includes support for multiple protocols & “services”, leads to interop challengesHTTP SOAP-like architecture not best fit for features/services provided (federation, publish/subscribe)Option for clear text transportROLIEREST HTTP/TLSInternal networks, trusted partner, or open accessEnables searchSecure access controls by user/roleEncryption of data at rest difficultPush model preferred for emergency notificationsXMPPGood for complex environments.Proven scalability and interoperabilityIntegrated in incident response toolsFederationPublish/subscribeOTR used for end-to-end encryption, more robust solution in developmentDetermine Best FitRID Implementations:TAXII Open Source Implementations:https://github.com/TAXIIProject see also: https://taxii.mitre.org/ROLIE Implementations: NoneXMPP Open Source Implementations:
25Open Source Implementations Transport optionsRID Implementations:implementreport-00TAXII Open Source Implementations:https://github.com/TAXIIProjectSee also: https://taxii.mitre.org/ROLIE Implementations: NoneXMPP Open Source Implementations:*Numerous interoperable open source implementations!
27IETF’s MILE MILE Overview Charter: Current list of drafts: Charter:Current list of drafts:RFC5070-bisIODEF Enumeration Reference FormatIODEF GuidanceRESTful indicator exchange using IODEF/RIDCyber physical extensionPLASMA for improved security
28MILE Decisions for Transport Why does RID provide publish/subscribe? Not a good fit for HTTP protocol, already available in XMPPWhy doesn’t RID have a robust query capability?Not a good fit for HTTPPuts onus of query on receiver, preferred method was search provided in ROLIE (RESTful architecture)Does RID support hub-n-spoke?Yes, but XMPP’s federation capabilities are superior and well tested, providing a more flexible optionImplementation supportXMPP has hundreds of interoperable implementationsWell tested and already used by incident respondersRID also has multiple interoperable implementations, but is not intended for wide-scale deployments that XMPP could better support
29Security Automation & Continuous Monitoring (SACM) Your help is needed on draft reviews and submissions!Why should I care about SACM?With automated security management, vulnerabilities and exposure risks could be identified and eliminated faster. This leaves us with less information to exchange on indicators and incidents.Get to the root of the problem: Secure your infrastructure!SACM Overview & CharterSACM Drafts:SACM TerminologySACM Use CasesSACM RequirementsSACM Telecom RequirementsSACM TNC Architecture
30Extensible Messaging and Presence Protocol (XMPP) Why not use one protocol? – XMPPXMPP Overview and CharterAdditional information:XMPP Documents:Reviews needed from YOU on end-to-end encryption:https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/
32IETF (Re)Action to Pervasive Monitoring Overall: snowdonia has re-energised folks to do better on security and privacy in general (and not solely in response to PM)Side meeting in IETF-87Tech plenary, major IETF-88STRINT workshop before IETF-89Topic at many IETF-89Wanting to see results from IETF-90 onwards…Unsurprisingly this is similar to the more broad technical community reactionSee Stephen Farrell’s talk from Terena May 2014This slide and the following slides were derived from:https://tnc2014.terena.org/core/presentation/83
33Opportunistic Security IETF security work has IMO tried to gold-plate key management too muchOnly ~30% of web sites doing any form of TLS after 20 yearsOpportunistic security provides a way to get much easier deployment for some intermediate level of securityNot plaintext (but might fall-back)Endpoints may or may not be one-way (think TLS server-auth), mutually, or just not authenticatedFB stats reporting 58% of MTA-MTA mail using STARTTLS with about half of that being “opportunistic” and half with a strictly authenticated endpointhttps://www.facebook.com/notes/Terminology debate:Opportunistic encryption → Opportunistic Keying → Opportunistic SecurityHappening on saag list, hoping to finish soon with informational RFCdraft-kent-opportunistic-security is getting close, another simpler approach in list from Viktor DukhnovniBogus argument: that could give a false sense of security!!!Protocols do not give any sense of security, implementations (with UI) doAsk your browser/web-server-config s/w authors about that one, not the IETF
34New IETF Work Related to Pervasive Monitoring (PM) “Pervasive Monitoring Is an Attack”RFC7258/BCP188 published after major IETF LC debate – sets the basis for further actionshttps://www.rfc-editor.org/rfc/rfc7258.txtBCP says to consider PM in IETF workOld-RFC privacy/PM review team formedPlease help! Mail Security ADs – sec- .IAB re-factoring security and privacy programs into one
35IETF Work related to PM Using TLS is Applications (UTA WG) Update old RFCs on how to use TLS in applications and mandate implementation of non-PFS ciphersuitesGeneric BCP for TLS ciphersuitesTLS 1.3 (TLS WG)TLS 1.3 being developed aiming for better handshake performance and encryption propertiesAnd learning from our history of previous TLS problemsHTTP/2.0 (HTTPBIS WG)Major deployment model: HTTP over TLSSignificant debate: concept of http: URIs being accessed via TLS (alt-svc), with no browser indication that crypto is happeningDebate on requiring server authTCP Increased Security (TCPInc)Provide TLS functionality within TCPSupport Opportunistic security with a way to hook in authenticationDNS PrivacyReducing exposure of sensitive names found in DNShttps://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-dns-privacy/UTAGeneric BCP for TLS ciphersuites– draft-ietf-uta-tls-bcp● Other drafts exist or coming on:– Attacks seen against TLS– XMPP, mail etcTCPInc:Was TCPCrypt, so the mailing list can be found at: archive/web/tcpcrypt/current/maillist.htmlCharter: https://datatracker.ietf.org/doc/charter-ietf-tcpinc/DNS Privacy list: https://www.ietf.org/mailman/listinfo/dns-privacy
36How Can I help? Participate in the IETF working groups: Volunteer DrivenRFCs can be updated as needed, with or without a working group in futureMeetings are held three times a yearMeeting dates/times can be found at:Participation can be in person or remote via MeetEchoAll decisions are finalized on the mailing listJoin working group mailing list, for example:Participate in an existing threadStart a thread on any questions based on review of a draftStart a thread on work to be proposed related to MILEReview background information on working groups including implementation information:List of working groups:Contribute to open source code implementing standardsProvide feedback on code and associated RFCs and draftsJoin the Privacy/PM Review team:Or submit a ticket with your review information: https://trac.tools.ietf.org/group/ppm-legacy-review/wikiPlease contribute to IETF Working groups!MILE mailing list:SACM mailing list:XMPP mailing list:Or any other that interests you!