Thread by @JBizzle703

I've been seeing some tweets about #BlueTeam and documentation and diagrams. Diagrams are an important part of the engineering process! So, I figured I'd do a little diagram breakdown for folks wondering what are some useful types of diagrams.

High level diagrams provide a non-technical overhead perspective of the environment. If you are at all familiar with DoDAF, this would be like your OV-1 diagram. These should tell a high level story and be easily explainable to someone who is new/and or non-technical.

Network level diagrams show logical connectivity between all nodes/devices in the environment. It should include the IP/hostname of the devices. Other details to include are VLAN information, system/authorization boundaries, as well as any unique information that might make sense

For instance, I like to take a base-level network diagram and overlay unique security controls in callout boxes. This in turn makes a useful INFOSEC diagram identifying and explaining security attributes at key locations to share with auditors or approval authorities.

Physical connectivity diagrams are useful (but tedious to maintain) and sometimes important when you need some type of approval or accreditation of your system. I believe this is better suited in a spreadsheet (It also makes labeling cables in a data center 100 times easier.).

However, you might have a specific requirement for putting that information into a diagram. This is one of the harder diagrams to put together if the environment is large and has a lot of components with connections. This information is better collected via automation.

Sometimes, a data flow diagram is needed on a particular service you have in your network. For instance, maybe you have an application service that is opened up to a user on the Internet. It would be good to document the service flow for the engineering and INFOSEC teams.

For this, I would utilize a diagram showing the full logical connectivity and data flow from a potential user on the Internet, through the premise equipment into the organization’s DMZ, terminating on a proxy/load balancer, and then connecting to an internal application server.

Laying this out so you can see the data flows between each segment can help identify potential service and security impacts. Often times, diagrams like these are required in organizations that have change review board (CRB.)

These are my top 4 types of diagram. There are other ones that are important as well, rack diagrams, software architecture diagram, process diagrams, etc...

And remember diagrams are only part of the overall documentation you should have (we can go into that more later)!

If you read all this way, I'd love to hear your thoughts on diagrams!

If you liked this, check out my YouTube channel : youtube.com/c/cyberinsight

Also, sign up for my blog and newsletterThumbs up
mailchi.mp/e7b56addb7fc/c…

Thought ya'll would appreciate this thread..

@L0Psec
@Teck923
@RyansNotAHacker
@akolsuoicauqol
@JediMammoth
@varcharr
@brianwhelton(you liked the ACL one, this is kind of network security related)