Creating sportscards for entities – Challenges abound when you look to create the sportscards for entities (the context is here). An entity’s card is a listing of all the directly-associated, definable information we have data for. Trouble often is, we don’t know what we don’t know – perhaps you’ve ideas of what it should include, but as more datasets are uncovered or created you may find other elements needing included. The point is – remain flexible in creating the entity cards, as the more you find, the more relevant the entity will be as you look across the maps. Caveat – make certain you aren’t mixing two entities in a single card.

The entities are the blocks in creating your organisation’s map. These are the pieces I’d look to build first, in relative order:

1. People – very first layer to create, foundational in mapping an organisation. We talk about putting people first, here we truly show how people are what the organisation is built on. Every other entity, be it physical or digital will end up connecting to a person. As this layer is crucial, I’ll break it out a bit further.
   1. Basic data – card – name, title, org, location (can be tied to a global map layer so you can see where people are).
   2. Hierarchy – relationship – superiors/ subordinates/ matrixed reports in either direction. (Nesting teams will be in the next post)
   3. Permissions – card/ relationship – this can go either way, depending on where you are in the build. Initially it may be best to have the admin/ read/ write permissions listed in a person’s card until you have entities created for the apps/tools for them to have a relationship established. Even then, if there is a dataset for the permissions of different Sharepoint sites (for example) it might be good to have that listed in the person’s card – unless you are looking to build out entity cards for those sites.
   4. PII – card – personal data not publicly visible. Evaluations, pay, associated programs (thinking tuition assistance or internships), benefits – this gives you an understanding of what people would be most interested in using/ taking part of. Looking at it over time can show trends within the workforce – lower evaluations in a particular sector or part of the org might warrant further enquiry.
   5. Authorisation/ approval – card (most likely) – known decision-making responsibilities. Who gives the green light for x? This is more for once you have a program layer (also next post).
2. Assigned devices – From the people layer, the next logical layer is the devices tied to those people. Some of these will be tied to the individual and assigned (remote desktop or phones) and as such may come from a fairly static dataset. There also may be a real/near-real time dataset worth keeping tabs on for when someone signs into a shared terminal. The ability to show relationships between people and their devices raises a potential to see when a person’s credentials are being used in a different location or on a different machine than should or could be – useful against account takeover or insider threats. Basic device entity cards would have identifiers such as Mac addresses or IMEI, operating systems and versions, initially having a listing of apps/software. As time goes on and the apps/software have their own entity cards, it will be good to see the relationships (especially when tracking versions, as then you can see the patching/update status)
3. Servers tied to devices (including cloud as appropriate) – This is often backwards from the understanding of how to build network topographies, as the intent is different. If we are looking from the most vulnerable points (namely users) we want to see where they connect to and who else is connected. This gives us a sense of where may be impacted in incidents or some lateral movement of bad actors. All the entity’s identifier data, both digital and physical, should be in the card.
4. Servers hosting software/ applications in use – a close second to the servers directly tied to the devices would be those hosting apps and software. Not the entity created for the app, rather the device entity hosting the app. There may be multiple entities hosting the same app, there may be multiple apps hosted on the same server. If either the server or app goes down, we want to see where the impact will be felt.
5. Other Devices tied to the servers – here are a few other device categories to build into the map:
   1. IoT – all the other devices falling into the IoT category, cameras, sensors, etc. Knowing the identifiers, location, and version. The relationships would be to controlling devices or router connections.
   2. ICS/ SCADA/ PLCs etc devices – manufacturing/data centre devices and their connections.
   3. Routers – listing the thoroughfare which devices connect through.
   4. Shared devices not tied directly to individual(s)
6. Software/ apps – should be a separate entity from the host/ user devices. Likely different versions should be independent entities, so it is quickly identified who would be impacted by an exploited vulnerability (for example).
7. Products/ services – we also use a variety of other products and services not tied to networks, identifying admins and users may help in mapping other processes and risks (in another post).
8. Vendors – third-party entities would have identifiers such as name/ location/ point-of-contact and relationships to the product/ service/ app etc they provision as well as the business account owners.
9. Clients – entities for clients and their relationships to people will be of use as we add process layers.

The basic, layered structure of entities and relationships will be organically grown and adjusted over time as more data is found and incorporated. Next post, we will look at layers we overlay to map end-to-end processes, business continuity, risk and controls, and the organisation’s ecosystem.

-scl