[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Common CybOX Object Refactoring
|
Hi Ivan, >I do think that we need a way of tracking the Assigned IPv4 and IPv6 addresses compared
to AS number as well, such as assigned by Regional Internet Registries (https://www.apnic.net/publications/research-and-insights/by-rir). I’m not sure if I’m understanding this correctly; are you suggesting that we add the ability to associate
an IPv4/IPv6 address with its assigning RIR? It’s more mapping the assigned IPv4/IPv6 ranges assigned to the Organization. So its about the RIR WHOIS data:
https://dig.whois.com.au/ip/8.8.8.8 You can often use this information when looking at malicious websites to determine that whole IP ranges are bad, and used to host only
malicious content. You can also use it to identify extra threat intel to help see the same TTPs based on what hosting providers they use and how they structure their operations:
# start NetRange: 8.0.0.0 - 8.255.255.255 CIDR: 8.0.0.0/8 NetName: LVLT-ORG-8-8 NetHandle: NET-8-0-0-0-1 Parent: () NetType: Direct Allocation OriginAS:
Organization: Level 3 Communications, Inc. (LVLT) RegDate: 1992-12-01 Updated: 2012-02-24 Ref: http://whois.arin.net/rest/net/NET-8-0-0-0-1 OrgName: Level 3 Communications, Inc. OrgId: LVLT Address: 1025 Eldorado Blvd. City: Broomfield StateProv: CO PostalCode: 80021 Country: US RegDate: 1998-05-22 Updated: 2012-01-30 Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE Ref: http://whois.arin.net/rest/org/LVLT OrgTechHandle: IPADD5-ARIN OrgTechName: ipaddressing OrgTechPhone: +1-877-453-8353
OrgTechEmail: ipaddressing@level3.com OrgTechRef: http://whois.arin.net/rest/poc/IPADD5-ARIN OrgAbuseHandle: APL8-ARIN OrgAbuseName: Abuse POC LVLT OrgAbusePhone: +1-877-453-8353
OrgAbuseEmail: abuse@level3.com OrgAbuseRef: http://whois.arin.net/rest/poc/APL8-ARIN OrgNOCHandle: NOCSU27-ARIN OrgNOCName: NOC Support OrgNOCPhone: +1-877-453-8353
OrgNOCEmail: noc.coreip@level3.com OrgNOCRef: http://whois.arin.net/rest/poc/NOCSU27-ARIN # end # start NetRange: 8.8.8.0 - 8.8.8.255 CIDR: 8.8.8.0/24 NetName: LVLT-GOGL-8-8-8 NetHandle: NET-8-8-8-0-1 Parent: LVLT-ORG-8-8 (NET-8-0-0-0-1) NetType: Reallocated OriginAS:
Organization: Google Inc. (GOGL) RegDate: 2014-03-14 Updated: 2014-03-14 Ref: http://whois.arin.net/rest/net/NET-8-8-8-0-1 OrgName: Google Inc. OrgId: GOGL Address: 1600 Amphitheatre Parkway City: Mountain View StateProv: CA PostalCode: 94043 Country: US RegDate: 2000-03-30 Updated: 2015-11-06 Ref: http://whois.arin.net/rest/org/GOGL OrgAbuseHandle: ABUSE5250-ARIN OrgAbuseName: Abuse OrgAbusePhone: +1-650-253-0000
OrgAbuseEmail: network-abuse@google.com OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE5250-ARIN OrgTechHandle: ZG39-ARIN OrgTechName: Google Inc OrgTechPhone: +1-650-253-0000
OrgTechEmail: arin-contact@google.com OrgTechRef: http://whois.arin.net/rest/poc/ZG39-ARIN # end So being able to track the IP address ranges and the organizations (Identity) that the IP address ranges are assigned to will help
when trying to determine if a particular IP is malicious. Another example. 1.1.1.1 is malicious. You see 1.1.1.2 and you are unsure. You look at your threat intel, and the 1.1.1.5 and 1.1.1.6
are also shown as malicious. You look at the IP WHOIS and work out that the 1.1.1/24 appears to have been involved in many attacks over the last few years. So you then know that you need to check 1.1.1.2 way more closely as it is way more likely to be malicious. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA | An FS-ISAC and DTCC Company +61 (407) 203 206 |
terry@soltra.com From: Kirillov, Ivan A. [mailto:ikirillov@mitre.org]
>Along with the whole DomainName is in the URI Object, yet FQDN and Top Level Domain are in the DomainName Object (that one has always puzzled me!). That’s something we should revisit soon; my hope is that we can run through the “simple” Objects (URI, DomainName, etc.) in one go and make any necessary changes
there. >As for the additional objects, I would say that ASN should be recorded in the separate object. Using relationships will allow us to use one AS object and relate
the IP addresses within that AS to the AS number easily. I agree, and it’s worth noting that we already have an AS Object [1] that captures AS Name, Number, and some other properties. >I do think that we need a way of tracking the Assigned IPv4 and IPv6 addresses compared to AS number as well, such as assigned by Regional Internet Registries
(https://www.apnic.net/publications/research-and-insights/by-rir). I’m not sure if I’m understanding this correctly; are you suggesting that we add the ability to associate an IPv4/IPv6 address with its assigning RIR? >The rest of the objects listed (ATM, IPv4 Netmask and IPv6 Netmask) don’t need to be moved to CybOX 3 right now. If there is a need for them in the future then
we can add them in a dot release. Agreed! Regards, Ivan From:
Terry MacDonald <terry@soltra.com> Hi Ivan, Address object: I really like the separating into different objects. In training that I’ve done in the past it’s invariably been the first question – why are email addresses
in the same object as IP addresses? Along with the whole DomainName is in the URI Object, yet FQDN and Top Level Domain are in the DomainName Object (that one has always puzzled me!). As for the additional objects, I would say that ASN should be recorded in the separate object. Using relationships will allow us to use one AS object and relate
the IP addresses within that AS to the AS number easily. I do think that we need a way of tracking the Assigned IPv4 and IPv6 addresses compared to AS number as well, such as assigned by Regional Internet Registries
(https://www.apnic.net/publications/research-and-insights/by-rir). This is important for discovering bulletproof hosting environments whose entire infrastructure aand IP address
rangers can be blocked as they are full of maliciousness. The rest of the objects listed (ATM, IPv4 Netmask and IPv6 Netmask) don’t need to be moved to CybOX 3 right now. If there is a need for them in the future then
we can add them in a dot release. File Object: It looks very logical. I’m not a host forensics guy, but I do like it. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA | An FS-ISAC and DTCC Company +61 (407) 203 206 |
terry@soltra.com From:
cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Kirillov, Ivan A. I’d like us to get to consensus on the Address and File Object refactoring; I’ve highlighted some of the open questions and current consensus below. If there are
no additional thoughts/comments by the end of the week, then I’d suggest that consensus has been reached.
Regards, Ivan From:
Ivan Kirillov <ikirillov@mitre.org> Sending this to the broader CTI list since it’s part of the STIX/CybOX Indicator tranche. Here’s a summary of the status of the refactoring of the most commonly used CybOX Objects (based on CTI-stats). Please let us know if you don’t agree with the consensus
status for Address and File, and also if you have any input on their open questions.
Accordingly, I would propose grouping and timeboxing the refactoring discussions as such:
Regards, Ivan |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]