You can’t reasonably defend something if you don’t know that it exists or what it does. Business Technology’s resident U.S. blogger Keil Hubert points out how simple security techniques from the Norman occupation of Britain are still highly useful to IT people today.
The phrase ‘We don’t know what we don’t know’ shows up fairly regularly in the cyber security world. It often comes across as a bit trite, like ‘Have you tried turning it off and turning it back on again?’ I admit, I’ve rolled my eyes a time or two at its utterance, and that’s unfair to the phrase. It actually has a great deal of resonance for those of us who work in the field.
The phrase first got popular back in 2002, when American Secretary of Defence Donald Rumsfeld – speaking at a NATO press conference in Brussels – said: ‘There are things we know that we know. There are known unknowns. That is to say there are things that we now know we don’t know. But there are also unknown unknowns. There are things we do not know we don’t know.’
That explanation earned our SecDef a fair bit of ridicule from the press, and it really shouldn’t have. He might have made his point more eloquently, but he did make his point. Neither a person nor an agency can be reasonably expected to prepare for or to properly respond to threats that they have no prior knowledge of. Should you feel chagrined that you didn’t know about something that seems obvious in retrospect? Sure; a bit. That’s fair. But embarrassment isn’t (and shouldn’t be taken as) an admission of incompetence. We all get caught off guard by situations and events that we’ve never encountered before. If we haven’t been exposed to an idea before, we won’t understand how to put it into context.
Case I point: I’m a bit embarrassed to admit that I had absolutely no idea who William the Conqueror was until last January. Yes, I’d heard the name alluded to before, but William had never come up in any of my history lessons when I was a schoolboy – mostly because he wasn’t American. US schools tend to be a bit… er… shall we say ‘hometown proud’. We only needed two so-called ‘world history’ courses to graduate when I was a kid. The first was ‘ancient’ history, and it focused on everything that happened before Aristotle’s time. The second was ‘modern’ history, and it really only covered the Greeks, the Romans, the Renaissance, and the ‘discovery’ of the Americas. World War II was glossed over in a week. I’m not insinuating that we had lessons on how George Washington valiantly rode a dinosaur into a laser pistol duel against a dragon-headed George III… but most of the flag-wrapped crap we were taught wasn’t too far off that mark.
By happenstance, I stumbled across one of Terry Deary and Martin Brown’s ‘Horrible Histories’ books on my first visit to the Imperial War Museum and was captivated by it. Last Christmas, when I found out that there was an HH ‘Blood Curdling Box’ set, I immediately ordered it from an online bookseller (because I can’t find them over here). I’ve been devouring those books at a rate of one book per lazy Sunday afternoon ever since the holidays. I finished the Stormin’ Normans volume last weekend, and in doing so I learned more about the first Norman King of England than I’d ever learned about the entire Norman period in American public schools.
One line that struck me came at the start of page eight: ‘1085 William the Conqueror orders the Domesday Book – a survey of everything everyone in England owns… so he can have a share. (Today’s government sill does that.)’ I’d never heard of the Domesday Book prior to that mention of it. I wish I had; that would have provided me with a solid analogy for my IT logistics team on how they could contribute to our organisational security programme.
As soon as I read that sentence from Stormin’ Normans, I immediately flashed sideways to the idea of end user equipment inventories, and their criticality in contemporary cyber security practices.  It’s so important to effective security controls, that it’s the very first entry in the SANS Technical Institute’s 20 Critical Security Controls:
Inventory of Authorized and Unauthorized Devices
Actively manage (inventory, track, and correct) all hardware devices on the network so that only authorized devices are given access, and unauthorized and unmanaged devices are found and prevented from gaining access.
This admonition is considered an inviolable commandment within the cyber security community. It’s a general rule that you can’t protect what you don’t know exists. Further, you can’t differentiate friend from foe on your network if you don’t know who your friends are, or how to recognize them.
If you were starting a new company, this would be one of the very first activities that your IT operations staff did once they stood up their first network: they’d build a small database that captured all of the critical information about each and every end-user device that the company owned. Each equipment item record would include (at a minimum) the device’s make, model, serial number, MAC IDs , date of purchase, warranty reference number, assigned user, and initially-assigned geographic location.
Bean counters usually insist that something like this happens straightaway, because they want to depreciate all of the company’s IT kit for tax purposes. They also want to project ahead; how far off do they need to budget for when it comes to equipment refreshes? Having a comprehensive inventory makes that process much more accurate, and avoids wasteful duplication. 
As a fortuitous side effect, an accurate equipment database will also be of immense value to the organisation’s service desk. For example, when a user calls in with a hardware problem, the help desk tech can immediately match a user’s stated problem to a list of known issues with the item type. It tells the tech whether or not the device is still under warranty if replacement parts are needed.
In the same vein, the database also helps the security team when it comes to implementing access control measures. That’s often far more important than most IT people appreciate. Situational Awareness (SA) is a critical part of a well-balanced security programme. Most IT heads overlook SA – or refuse to implement control measures that rely on SA. Access control is one simple technique that security teams can implement to greatly reduce opportunities for baddies to act up, so it confuses me when companies can’t be bothered with it.
Access control measures take effect the moment that an end-user device is issued a temporary network address. The server responsible for accommodating the newcomer checks the database of authorized devices to see if the requester has an approved MAC address. If it doesn’t find one, the offender doesn’t get an address, and therefore doesn’t get to talk. It’s a simple deny-by-default solution, and it works very well for thwarting amateur intruders.
At a more advanced level, your security team can build more restrictive controls into the network infrastructure itself. For example, you could configure the network switches to only allow certain known, trusted PCs to connect from certain buildings or even certain floors. Desktop PCs aren’t supposed to move about after they’re installed, after all. Even laptops, tablets, and company mobile phones might normally be restricted to the company buildings where the owning employee is based. When the employee travels, he or she can ask for special dispensation to connect to the network from other campuses for the duration of their official travel.
If these seem like draconian measures, well… yes. They are… a bit. If you’re interesting in keeping unauthorized machines off of your sensitive network, then this is a darned good first step to making it difficult for would-be attackers to communicate at all. Yes, a good hacker can find ways to masquerade as a legitimate user on a legitimate device with techniques like ‘MAC address spoofing’ and ‘man-in-the-middle’ attacks. They can also compromise one of your trusted machines with malware. That’s how professional hackers earn their title, after all; amateurs just plug and see what they can mess with, like yobbos performing a ram-raid on a shop.
Basic access control measures are designed to keep the riff-raff out, and to keep your employees from inadvertently compromising the network with their virus-saturated personal devices. It’s simple, and it works. Just like in Norman times, you put up guards at checkpoints inside the castle walls specifically to screen everyone trying to come through – if the guards don’t know you, then you won’t be allowed to come further inside the defensive perimeter. If you truly have legitimate business there, you can ask the security staff to assess your request and to validate your identity. Otherwise, you’re told to take a hike. That’s a much more prudent approach to security than trusting in one drawbridge on the outer curtain (e.g., the firewall separating the production network from the Internet) and then simply leaving all of the gates and doors inside the castle complex open and unguarded. Of course, instead of a human guard recognizing a face, your automated controls are querying your inventory database for known-approved network card addresses. It’s essentially the same process, though. William would approve.
Even if you never introduce machine-level access restrictions, an accurate inventory is still highly valuable to the security staff. If you’re fortunate enough to have a Security Operations Centre (SOC) – where very clever people monitor production traffic for irregularities – or if you have a ‘SOC-in-a-box’ security monitoring appliance that does that monitoring for you, an inventory of the company’s equipment will allow your security investigators to swiftly identify what a misbehaving node actually is, who it belongs to, what it does for the company, and where it’s supposed to reside.
In another Norman-era example, imagine a day in the life of William after his accountants finished his grand inventory of all the holdings in the British Isles. An advisor brings the king news that two noble lords are atypically buying up lots of arrows and chainmail. Rather than try and muster two armies simultaneously, the shrewd William checks his inventory. The lord who lives on the East coast has a history of getting raided by die-hard Vikings this time of year, so his investment in ordnance is probably just prudent planning. Probably nothing to worry about there. The lord who lives in Wales, on the other hand, doesn’t face any real threats and is noted as being sore that he didn’t get a better title. The wise king then dispatches a few hundred armoured thugs to the West to remind the petulant Welsh fellow about the king’s official policy regarding insurrection. Everything gets sorted, with minimal expenditure of constrained resources.
We use the same logic in the security world: when multiple alerts come into the SOC suggesting atypical behaviour, the SOC Chief looks over the comprehensive systems inventory and works out what-all kit is involved. Based on where something is, what it’s supposed to be doing, and who owns it, the security people can triage problems fairly accurately into prioritized queues. For example, a VPN concentrator reports that it’s being slammed atypically hard… in a region that’s recently been blasted by an ice storm. That’s reasonable, since all of the office employees will be telecommuting. It should be looked at, but not immediately. A database server that’s suddenly firing off hundreds of outbound HTTP requests makes no sense whatsoever – either some user is operating it as a personal workstation, or (more likely) it’s been infected with malware. That problem takes priority.
It’s pretty much that simple. Knowing what kit you have, where it is, what it does, and who uses it is the number one critical security control that SANS recommends – and that we in the field cleave to – because it’s staggeringly difficult to do our jobs without that knowledge. That’s why my colleagues and I advocate assembling your own Domesday Database as quickly as possible if you don’t have one already. Yes, it’s a lot of work – but it’ll save you a lot of wasted effort in the long run.
The techniques that we use for implementing security measures may be highly complex and difficult to configure, but the general principles aren’t. Most of the concepts have been well understood and practices for hundreds, if not thousands of years. It’s just a matter of translating them into actionable control measures and security policies. Now that I know a bit more about him, I’m sure that William the Conqueror would agree.
 Yes, I’m weird like that. No point in trying to deny it.
 Every Network Interface Card (NIC) installed on a computer has a unique Media Access Controller (MAC) identification number.
 I once worked for a company that purchased a lorry full of 15” LCD monitors for our general fleet… two years after we’d converted the whole company to 19” LCD monitors. The loggies at the national office never bothered looking at our IT inventory records, and wasted nearly thirty thousand quid on unnecessary, superfluous kit.
Keil Hubert is a retired U.S. Air Force ‘Cyberspace Operations’ officer, with over ten years of military command experience. He currently consults on business, security and technology issues in Texas. He’s built dot-com start-ups for KPMG Consulting, created an in-house consulting practice for Yahoo!, and helped to launch four small businesses (including his own).
Keil’s experience creating and leading IT teams in the defense, healthcare, media, government and non-profit sectors has afforded him an eclectic perspective on the integration of business needs, technical services and creative employee development… This serves him well as Business Technology’s resident U.S. blogger.