A quick note on Entity design
When designing an Entity you will need to decide whether your data should be stored in the property of the Entity or if the data should become a new Entity type. Similarly, consider whether only selected information should be displayed or stored as a property within an Entity.
Please consider the following criteria to assist in your decision making; if your Transform will regularly use a property of an Entity it would be better suited to create a separate Entity type. For example, it would be better to have SSN as an Entity type and have a Person to SSN Transform than to only have SSN as a property in the Person Entity (you might still store the SSN as a property within the Person Entity, but it makes better sense to have it as a separate Entity too). Similarly, if you cannot decide if something should be a property or simply display info, consider whether another Transform would need to read that property to work properly or if it’s only shown to the user for information (because display info is never passed back to the server). If it’s just only useful as display information don’t bloat the Entity by adding it as a property.
Best Practices when creating Entities
Entity creation is one of the most important steps when implementing Maltego in your environment. There are a few things to remember when doing this. Initially, we recommend creating a table of all the types of information that you have available and would like to integrate with on both the x-axis and y-axis and then determine where you will need Transforms and if any of the information is a duplicate. Once you have completed this you should have just the information you are interested in representing in Maltego and can then create these Entities.
- Dead end Entities - Dead end Entities are Entities that do not have any Transforms that can be run on them. It is important to try and re-use the default Entities or entities which you already have Transforms built for.
- Entity Inheritance - It is strongly recommended that if you have do have Entities that could be related to Entities pre-existing in the tool that you use Entity inheritance to avoid having to duplicate Transforms. An example of this is the website, NS record, and MX record that all inherit from the DNS Entity. This means that instead of having to recreate the 'to IP Address' Transform for each type we create it only once for the DNS record Entity and the Transform will be available to all of the different types.
- Entity Naming / Sharing - To avoid having Entities recreated by multiple people within a team it is recommended that a naming schema is used to categorize as well as share Entities across your organization/team. This also applies to the properties of Entities to avoid things like 'firstName', 'FIRSTNAME' and 'first.name' which will create a lot of confusion among developers.