MAPPING NETWORKS
For moving the camp, there is a set of principles to follow about the time and the day of moving. The duty of a shinobi is to know exactly the geography of the area and the distance to the enemy. —Yoshimori Hyakushu #9
Once you get the details and layout of the castle or the camp, all you need to do is get back with it as soon as possible, as that is what a good shinobi should do. Yoshimori Hyakushu #24
The very first piece of advice offered in the Bansenshūkai’s “A Guideline for Commanders” is to produce meticulously accurate maps that your generals can use to plan attacks against the enemy.[i] Selected poems of the Yoshimori Hyakushu[ii] also stress the importance of drawing and maintaining maps with enough detail to be useful to both an army and an individual shinobi.
Commanders usually tasked shinobi with creating maps. The scrolls make clear that the skill of being able to accurately draw what you see—mountains, rivers, fields—is not the same as drawing purposeful, contextualized threat intelligence maps to aid military strategy or shinobi infiltration. The scrolls state that the following details are relevant to the tactics of war and shinobi tradecraft and thus should be included in maps:[iii]
All entrances and gates of a house, castle, or fort. What types of locks, latches, and opening mechanisms are present? How difficult is it to open the gates or doors, and do they make noise when opened or closed?
The approaching roads. Are they straight or curved? Wide or narrow? Dirt or stone? Flat or inclined?
The design, makeup, and layout of the structure. What is each room’s size and purpose? What is kept in each room? Do the floorboards squeak?
The inhabitants of the structure. What are their names? Do they practice any noteworthy skills or arts? How alert or suspicious is each person?
The topology of the castle and surrounding area. Are signal relays visible from inside and outside the location? Where are food, water, and firewood stored? How wide and deep are the moats? How high are the walls?
Understanding Network Maps
Network maps in cybersecurity are network topology graphs that describe the physical and/or logical relationship and configuration between links (communication connections) and nodes (devices) in the network. To better understand the concept, consider road maps or maps in an atlas. These describe physical locations, geographic features, political borders, and the natural landscape. Information about roads (links)—their name, orientation, length, and intersections between other roads—can be used to navigate between different locations (nodes). Now let’s consider the following hypothetical scenario.
Imagine you live in a world where roads and buildings spontaneously appear or vanish in the blink of an eye. GPS exists, and you have the coordinates of where you are and where you want to go, but you must try to get there by following a bewildering network of constantly changing roads. Fortunately, navigation officials (routers) are placed at every crossroads to help travelers like you find their way. These routers are constantly calling their neighboring routers to learn what routes and locations are open so they can update their routing table, kept on a clipboard. You must stop at every intersection and ask the router for directions to the next corner by showing them your travel card, which has your intended destination coded in GPS coordinates. The router checks their clipboard for currently open routes while making some calculations, quickly points you in a direction, stamps your travel card with the router’s address, hole punches your travel card to track the number of routers you have checked in with on your journey, and sends you off to the next router. You repeat this process until you reach your destination. Now imagine this world’s cartographers, who would have likely given up on producing accurate maps, unable to keep up with the ever changing network. These mapmakers would have to be satisfied with labeling key landmarks and points of interest with generic names and drawing fuzzy lines between these points to indicate that paths of some sort exist between them.
This hypothetical situation is in fact what exists in cyberspace, and it’s why network maps are not as accurate and their maintenance is not as prioritized as it should be. The lack of high-quality, comprehensive network maps is a recognized challenge for cybersecurity organizations. If an organization has a map at all, it’s typically provided to the security operations center (SOC) to illustrate where sensors or security devices are in the flow of data and to better understand packet captures, firewall rules, alerts, and system logs. However, it’s probably also abstract, describing only basic features, such as boundaries for the internet, perimeter network, and intranet; the general location of edge routers or firewalls; and unspecified network boundaries and conceptual arrangements, indicated by cloudy bubbles. An example of an underdeveloped, yet common, network map available to cybersecurity and IT professionals is provided in Figure 1-1.
Figure 1-1: A simplified network map
To describe why Figure 1-1 is a “bad” map, let’s reexamine the Bansenshūkai’s advice on mapping in terms of the equivalent cyber details.
All access points of a node in the network. What types of interface access points are present on the device (Ethernet [e], Fast-Ethernet [fe], Gigabit-Ethernet [ge], Universal Serial Bus [USB], Console [con], Loop-back [lo], Wi-Fi [w], and so on)? Is there network access control (NAC) or media access control (MAC) address filtering? Is remote or local console access enabled or not locked down? What type of physical security is present? Are there rack door locks or even USB locks? Is interface access logging being performed? Where are the network management interface and network? What are the IP address and MAC address of each access point?
The bordering gateways, hops, and egress points. Is there more than one internet service provider (ISP)? Is it a Trusted Internet Connection (TIC) or Managed Internet Service (MIS)? What is the bandwidth of the internet connection? Is the egress connection made of fiber, Ethernet, coaxial, or other media? What are the hops that approach the network? Are there satellite, microwave, laser, or Wi-Fi egress methods in or out of the network?
The design, makeup, and layout of the network. What is each subnet’s name, purpose, and size (for example, Classless Inter-Domain routing [CIDR])? Are there virtual local area networks (VLANs)? Are there connection pool limits? Is the network flat or hierarchal or divided based on building structures or defense layers and/or function?
The hosts and nodes of the network. What are their names? What is their operating system (OS) version? What services/ports are they running, and which do they have open? What security controls do they have that might detect an attack? Do they have any known common vulnerability exploits (CVEs)?
The physical and logical architecture of the network and building. Where is the data center located? Are Ethernet jacks available in the lobby? Does Wi-Fi leak outside the building? Are computer screens and terminals visible from outside the building? Is security glass used in the office? Are guest/conference room networks properly segmented? What are the core access control lists (ACLs) and firewall rules of the network? Where is DNS resolved? What is available in the perimeter network or DMZ? Are external email providers or other cloud services used? How is remote access or virtual private network (VPN) architecture in the network?
Organizations without a working network map might instead reference wiring diagrams or schematics produced by their IT department. These simplified illustrations document the relative arrangement of systems, networking equipment, and device connections, and they can function as references for troubleshooting technical or operational issues within the network. However, too many organizations forego even these crude diagrams in favor of a spreadsheet that catalogs hostnames, model and serial numbers, street and IP addresses, and data center stack/rack rows for all equipment. If stakeholders can use this spreadsheet to locate assets and never have any major network issues or outages, the existence of such documentation may even discourage the creation of a network map. Appallingly, some companies rely on an architect or specialist who has a “map” in their head, and no map is ever formally—or even informally—produced.
To be fair, there are legitimate reasons for the lack of useful network maps. Building, sharing, and maintaining maps can eat up valuable time and other resources. Maps are also liable to change. Adding or removing systems to a network, changing IP addresses, reconfiguring cables, or pushing new router or firewall rules can all significantly alter the accuracy of a map, even if it was made just moments before. In addition, modern computers and networking devices run dynamic routing and host configuration protocols that automatically push information to other systems and networks without the need of a map, meaning networks can essentially autoconfigure themselves.
Of course, there’s an abundance of software-based “mapping” tools, such as Nmap,[i] that scan networks to discover hosts, visualize the network via number of hops from the scanner, use Simple Network Management Protocol (SNMP) to discover and map network topology, or use router and switch configuration files to quickly generate network diagrams. Network diagrams generated by tools are convenient, but they rarely capture all the details or context needed to meet the high-quality mapping standard that a defender or adversary would want. Using a combination of mapping tools, network scans, and human knowledge to draw a software-assisted network map is likely the ideal solution—but even this approach requires the investment of significant time by someone with specialized skills to remain accurate and thus useful.
Despite these limiting factors, it is crucial that defenders maintain mapping vigilance. The example map in Figure 1-2 illustrates the level of detail a defender’s map should include to protect a network.
Figure 1-2: A detailed network map
Distinctive shapes, rather than pictograms, are used to represent devices in the network. The same shape type is repeated for similar device types. For example, the circles in Figure 1-2 represent workstations, squares represent routers, and rectangles represent servers; triangles would represent email relays or domain controllers if they were present. In addition, the shapes are empty of texture or background, allowing information written inside to be clearly legible.
Every interface (both virtual and physical) is labeled with its the type and number. For example, the Ethernet interface type is labeled eth, and the interface is numbered the same as it would be physically labeled on the device, eth 0/0. Unused interfaces are also labeled. Each interface is given its assigned IP address and subnet when these are known.
Device information, such as hostname, make and model, and OS version are documented at the top of the device when known. Vulnerabilities, default credentials, known credentials, and other key flaws are notated in the center of the device. Running services, software, and open ports are documented as well. VLANs, network boundaries, layout, and structure should be designed into the network map and labeled as such, along with any noteworthy information.
Collecting Intelligence Undetected
For shinobi, collecting intelligence without being detected was an elite skill. Loitering near a castle while taking detailed measurements with a carpenter square or other device would tip off the inhabitants, exposing the shinobi as an enemy agent. Consequently, industrious shinobi made maps during times of peace, when the occupants of fortifications lowered their guard; at these times, shinobi could travel more freely and invite less suspicion as they collected data.[i]
Often, however, shinobi had to come up with ways to furtively take measurements, note topographical features, and gather other intelligence. Tellingly, the Bansenshūkai includes a description of how to accurately produce maps in a section about open-disguise techniques, indicating that shinobi used deception to conduct mapping within plain sight of the enemy. The scroll references a technique called uramittsu no jutsu[ii]—the art of estimating distance—that involves finding the distance to a familiar object using knowledge of the object’s size for scale. Uramittsu no jutsu also incorporated clever trigonometry tricks; for example, a shinobi might lie down with their feet facing the target and use the known dimensions of their feet to take measurements, all while appearing to nap under a tree.
Collecting network bearings is one of the first things adversaries do before attacking a target network or host. Adversary-created maps have the same purpose as historical ninja maps: identifying and documenting the information necessary to infiltrate the target. This information includes all egress and ingress points to a network: internet service provider (ISP) connections; wireless access points; UHF, microwave, radio, or satellite points; and cloud, interconnected, and external networks.
Attackers will also look for Border Gateway Protocol (BGP) gateways and routes or hops to the network. They’ll look for the network’s representational structure, layout, and design; network inventory including hostnames, appliance models, operating systems, open ports, running services, and vulnerabilities; and network topology such as subnets, VLANs, access control lists (ACLs), and firewall rules.
Many of the network-mapping tools attackers use are “noisy,” as they communicate to large numbers of hosts, use custom packets, and can be detected by internal security devices. However, attackers can mitigate these weaknesses by slowing or throttling the network mapper, using non-custom (non-suspicious) packets, and even performing manual reconnaissance with common tools that already exist on the victim host, such as ping or net. Attacks can also use innocuous reconnaissance methods, in which the attacker never touches or scans the target but instead collects information using Shodan or other previously indexed data found via internet search engines.
More sophisticated adversaries develop tradecraft to perform passive mapping, a tactic whereby the attacker collects information about a target without interacting directly with it (without actively scanning it with Nmap, for example). Another passive mapping tactic is the interpretation of packets captured from a network interface in promiscuous mode, which configures a network interface to record and inspect all network communications; this is the opposite of non-promiscuous mode in which only communication the network addresses to itself is recorded and inspected. You would use promiscuous mode to gain an understanding of the neighboring hosts, traffic flow, services, and protocols used on the network without ever actively interacting with it.
Another method for mapping a network without directly interacting with it is to collect a network admin’s emails as they leave the network, searching for network maps of the target in an external file storage-sharing environment, or looking in third-party troubleshooting help forums where the admin may post logs/errors, router configurations, network debugging/tracert/ping, or other technical details that disclose the layout and configuration of the network. Much like the ninja’s uramittsu no jutsu technique, the exploitation of observable information from a target’s network can be used to map it without alerting the target. Passive mapping can include measuring the latency of recorded tracerts from the network to identify satellite hops (for example, the presence of a satellite is indicated by a sudden 500-millisecond increase in communication delay) or detecting a firewall system’s deep-packet processing (for example, the preprocessor recognizes a potential malicious attack and adds perceptible delays to specially crafted communication). Passive mapping might also include information disclosure of the internal network from external DNS zones and record responses; public procurement orders and purchase requests for certain software/hardware; or even job postings for network/IT admins with experience in a specific technology, networking equipment, or hardware/software.
After the attacker has spent so much time developing them, their maps may be more complete than the target’s own—the adversary may know more about the target’s network than the target does. To offset any such advantage, network defenders should strive to develop and maintain superior maps and keep them highly protected.
Creating Your Map
The map creation process can happen in three general steps:
1. Make the necessary investment to create a comprehensive, accurate map that can be easily updated and securely stored. It should contain the information necessary for each team’s use case (such as IT, network operations center [NOC], and SOC). Consider hiring a dedicated person or team, or an outside vendor, to make and analyze the map.
2. Make the map, including the types of precise details specified in the beginning of this chapter.
3. Request that the map be peer reviewed as part of change management requests, as well as whenever anyone notices an incongruity in or divergence from the map.
Let’s take a closer look at the second step: making the map.
After you have identified all key stakeholders and persuaded them that this project should be a priority, the first step is to gather anything and everything your organization has internally that could help with the mapping process. This includes wiring diagrams, old network architecture project plans, vulnerability scans, asset inventory lists, inventory audits of the data center, DHCP leases, DNS records, SNMP network management data, endpoint agent records, packet captures (PCAP), SIEM logs, router configurations, firewall rules, and network scans. Router configurations should be the primary source for constructing the major architecture and layout of your network map; consider starting by putting your core/central router(s) in the middle of your map and branching out from there. PCAP captures can reveal endpoints communicating on the network that may not respond to network scans or that cannot be reached by scans due to network filtering. After you allow select systems to collect PCAP for an extended period in promiscuous mode, it will be possible to review the list of endpoints found in the PCAP, as seen in Figure 1-3.
Figure 1-3: Wireshark screenshot of endpoints discovered during PCAP collection
Ideally, PCAP collection should occur during network scans to validate the reach of the scans. Also, multiple network scans should be conducted, with a minimum of one endpoint per subnetwork conducting a scan of its subnet; these scans can be manually stitched together into a network map topology, as shown in Figure 1-4. Identify items that can be automated so this process is easier to repeat in the future.
Figure 1-4: The Zenmap topology view of a scan of the 10.0.0.0/24 subnet
Once all the data has been collected, it will need to be processed, analyzed, and merged. It will be useful to find out which source of data is the most accurate as well as to identify data sources with unique and helpful information (for example, the last-seen-time of a device) before consolidating all the data. Also, any incongruities and discrepancies should be investigated. These might include devices missing from the network, rogue devices in the network, and strange network behavior or connections. If you discover that your network scanners were not able to penetrate certain enclaves or subnets due to IP rules or intrusion prevention systems (IPSs), consider requesting network changes to allow deeper and more comprehensive scanning. A key outcome from this stage of the project is the identification and location of all authorized and unauthorized devices connected to your network—a huge accomplishment.
Evaluate software-mapping tools that can automatically ingest SNMP data, network scans, and vulnerability scans and allow manual editing to incorporate any additional data. The tool you choose should produce a comprehensive, accurate, and detailed network map that meets your stakeholders’ needs. Pick the best solution that will handle your data and meet your budget.
Produce the map and test it. Test its usefulness during change management meetings/security incidents and network outage/debugging events. Does it help resolve issues and find problems faster? Test its accuracy with traceroutes and tcpdumps over interfaces. To test the accuracy with traceroutes, conduct internal and external traceroutes from different network locations to see whether the hop points (routers) are present in the map and flow logically according to your map. An example traceroute is seen in Figure 1-5.
Figure 1-5: A Windows traceroute to example.com
See what your red team and blue team can do with your map. Collect feedback and perform the mapping process again with the goal of producing an even better map in less time.
Castle Theory Thought Exercise
Consider the scenario in which you are the ruler of a medieval castle with valuable information, treasure, and people within your stronghold. You receive credible threat intelligence that a ninja has thoroughly mapped your castle and surrounding area, though it is unclear whether this activity was part of active targeting or just passive reconnaissance. You don’t know what the map looks like or how detailed it is. Your only map of the castle is an architectural design plan that was used during initial construction—and was designed for the builders and not for other users—but has since become out-of-date.
What does the ninja’s map likely include that your map doesn’t? What would the ninja know about your castle that you don’t, and how could that information be used for infiltration? Who in your fiefdom would benefit from access to the ninja’s map? Whom would you trust to map your castle in the same way the ninja did, allowing you to see what the ninja sees?
Recommended Security Controls and Mitigations
Where relevant, each recommendation is presented with an applicable security control from the NIST 800-53 standard, and it should be evaluated with the idea of maps in mind.
Assign responsibilities for documenting a network map. Implement policies and procedures to coordinate updates of the map between teams.
CM-1: Configuration Management Policy and Procedures
CM-3: Configuration Change Control | (4) Security Representative
CM-9: Configuration Management Plan
To establish a baseline, document the configuration of the network’s topology, architecture, logical placement, and information systems.
CM-2: Baseline Configuration
Incorporate flaw identification (such as map inaccuracies) and remediation (for example, of vulnerabilities inherent in the network architecture) into the network-mapping process.
SI-2: Flaw Remediation
Summary
In this chapter, you got a review of shinobi mapping objectives, map standards, and mapping techniques as well as an overview of modern network-mapping practices and technologies. Considering the importance of network maps, how to create (good) maps, and how attackers collect intelligence on your system may have sparked your imagination, and you may have thought of new data sources or techniques you could use to map your own network and others’ networks.
In the next chapter, you will get a chance to use your network map as a type of data flow diagram (DFD) to perform threat modeling. This means you’ll identify areas in your network where a threat actor is likely to attack it or bypass your defenses to infiltrate it. I’ll discuss the novel ninja security technique of “guarding,” which can be used to defend these weak points in your network .
