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:
OrgTechRef: http://whois.arin.net/rest/poc/IPADD5-ARIN
OrgAbuseHandle: APL8-ARIN
OrgAbuseName: Abuse POC LVLT
OrgAbusePhone: +1-877-453-8353
OrgAbuseEmail:
OrgAbuseRef: http://whois.arin.net/rest/poc/APL8-ARIN
OrgNOCHandle: NOCSU27-ARIN
OrgNOCName: NOC Support
OrgNOCPhone: +1-877-453-8353
OrgNOCEmail:
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:
OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE5250-ARIN
OrgTechHandle: ZG39-ARIN
OrgTechName: Google Inc
OrgTechPhone: +1-650-253-0000
OrgTechEmail:
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 |
From: Kirillov, Ivan A. [mailto:]
Sent: Wednesday, 24 February 2016 2:52 AM
To: Terry MacDonald <>;
Subject: Re: Common CybOX Object Refactoring
>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!
[1] http://stixproject.github.io/data-model/1.2/ASObj/ASObjectType/
Regards,
Ivan
From:
Terry MacDonald <>
Date: Monday, February 22, 2016 at 2:43 PM
To: Ivan Kirillov <>, "" <>
Subject: RE: Common CybOX Object Refactoring
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 |
From:
[mailto:]
On Behalf Of Kirillov, Ivan A.
Sent: Tuesday, 23 February 2016 2:36 AM
To:
Subject: [cti] Re: Common CybOX Object Refactoring
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.
Address Object
Proposal: https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-Address-Object-Refactoring
Open questions:
Should Email Address be a separate Object, or should it instead be a property of a different Object (e.g., User Account)?
Current consensus: Email Address should be a separate Object, for purposes of sharing individual email addresses (e.g.,
as associated with a Threat Actor)
File Object
Proposal: https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-File-Object-Refactoring
Open questions:
Are there any additional properties that belong in the base set of properties or basic set of file system properties?
Current consensus: no additional properties have been raised.
Which default extensions should be included with the Object?
Current proposed list:
File Metadata
EXT3 File
NTFS File
Image File (based on existing Image File Object)
PDF File (based on existing PDF File Object)
Archive File (based on existing Archive File Object)
PE Binary File (based on existing Windows Executable File Object)
Regards,
Ivan
From:
Ivan Kirillov <>
Date: Tuesday, February 9, 2016 at 11:52 AM
To: "" <>
Subject: Common CybOX Object Refactoring
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.
Address Object
Proposal: https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-Address-Object-Refactoring
Consensus largely reached
Open questions:
Should Email Address be a separate Object, or should it instead be a property of a different Object (e.g., User Account)?
Artifact Object
Not discussed yet
May require some changes
Domain Name
Not discussed yet
Likely requires very little in the way of changes
Email Message
Not discussed yet
May require some changes; we’re considering creating a base “Message” Object for use in Email Message as well as SMS Message
File Object
Proposal: https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-File-Object-Refactoring
Consensus largely reached
Open questions:
Are there any additional properties that belong in the base set of properties or basic set of file system properties?
Which default extensions should be included with the Object?
Current proposed list:
File Metadata
EXT3 File
NTFS File
Image File (based on existing Image File Object)
PDF File (based on existing PDF File Object)
Archive File (based on existing Archive File Object)
PE Binary File (based on existing Windows Executable File Object)
Hostname
Not discussed yet
Likely requires very little in the way of changes
HTTP Session
Not discussed yet
May require some significant refactoring, related to the refactoring of Network Connection
Link
Not discussed yet
Likely requires very little in the way of changes
Memory
Not discussed yet
May require some changes
Mutex
Not discussed yet
Likely requires very little in the way of changes
Network Connection
Not discussed yet; proposal forthcoming
May require significant refactoring
PDF File
Not discussed yet
May require some changes; likely to be included as an extension of the File Object
Port
Not discussed yet
Likely requires very little in the way of changes
URI
Not discussed yet
Likely requires very little in the way of changes
WhoIS
Not discussed yet
May require some changes
Windows Executable File
Not discussed yet
May require some changes; see https://github.com/CybOXProject/schemas/issues?q=windows+executable+file+is%3Aopen
Windows Registry Key
Not discussed yet
Likely requires very little in the way of changes
Accordingly, I would propose grouping and timeboxing the refactoring discussions as such:
Network Object Refactoring – Network Connection and HTTP Session
2 weeks
Messaging Object Refactoring – Email Message and SMS Message
1 week
Other Atomic Network Object Refactoring – Domain Name, Hostname, Port, URI, and Link
1 week
Host Object Refactoring – Windows Executable File, Windows Registry Key, PDF File, and Mutex
1 week
Other Object Refactoring – WhoIS and Artifact
1 week
Regards,
Ivan
