Ancient castles weren’t just guarded by stone walls; they had multiple layers of defense. Here’s how to apply castle architecture to your own software design by securing your systems on multiple levels.
We bandy about terms like “firewall” to represent the way we protect IT services and software applications, but the analogies have a very real origin and relevance to application design.
Take the castle. Used for protection and defense, medieval castles’ architecture evolved, like software systems, to include more and different types of protection, such as the two-wall defense system.
A multiple-wall defense.
Castles weren’t just one big wall around a town. They had several layers of defense – and it’s instructive to consider how to use their architecture in designing your own applications for optimal security.
The Front Gate
The easiest way into Windsor Castle? The front door.
Castles usually have a big door called the gate. That’s no surprise; the population inside the walls need to get lots of food, people, animals, and fuel into the castle. An open gate with a few guards is great in peacetime, but during war, the gate is a huge security hole.
On the Internet, that big hole is Web traffic, designed to let requests go right on in and be handled by the web server. When the traffic is trusted – peacetime – you want to minimize barriers to entry. But it has to be easy to drop into protection-mode, too.
The castle lords built multiple layers of defense over the target: a portcullis, a draw bridge, a moat. In the late middle ages, lords built towers over the top of the drawbridge from which to fire arrows or to dump boiling oil. Later castles had two portcullises, to trap invaders between them, and fire arrows through slits in the floor called “murder holes.”
These multiple layers of protection, perhaps even redundant layers, ensured that if one barrier didn’t stop the enemy, another one would. For designing secure software applications, that means a second system can compensate for vulnerability that the first didn’t catch, and prevent a breach.
We may put up a drawbridge and an inspection layer to make sure arriving traffic is safe. In computer terms, that would be web server traffic, requests for pages, form submits, and so on.
A malicious user can go through the front gate by attaching computer code to those form submits. In fact, according to the Open Web Application Security Project (oWasp), injecting code onto web pages is the most popular kind of server attack, generally cross-site scripting and SQL injection.
For example, you can start by creating a whitelist of acceptable characters (a-z, A-Z, 0-9, perhaps a period, @ sign, or hyphen), and have the software strip out anything else before we process it. On top of that, we’ll check the programming language (to the left on bobby-tables.com) to make sure the programmers used named parameters any time they used SQL directly. Better yet, use a tool like nHibernate that writes the SQL for us, and protects us from SQL injection mistakes. If the application allows us to type in markup codes, we want to be especially careful.
Train Castle Guards in the Security Protocol
Simple passwords make it far too easy for enemies to walk in the front gate. Changing the software to require medium-strength passwords (eight letters, a capital, and one special character) virtually eliminates random guessing by the bad guys, especially if we lock out users after five attempts (the NIST standard for Windows security is three) and require another challenge – like the castle guard at the front gate.
Depending on the nature of the content your site offers, an additional level of security might include scrambled characters on the screen that a human can translate easily require extra effort on the part of hackers – and extra effort means an investment in time and money.
One way to accomplish this is with captcha. Google offers its re:Captcha service for anyone at no charge; the end client just needs access to the Internet.
Spies and Sneaks
So we have a strong password; that’s good. But if our villagers share the password a little bit too much in public and the enemy hears it, then we’ve got a problem.
Two ways the bad guys can do this is to sniff an unencrypted public network, or shoulder-surf someone typing.
Locking down public networks is relatively easy: Require a secure login with something like SSL. The ultimate website test is from a public access point (such as a coffee shop) using Wireshark. If we can see our password in clear text, so can everyone else.
To consider shoulder surfing, look at password during the login process. Displaying asterisks is good, clear text is bad. Also look at the URL after login. If it has encoded parameters, like http://www.mysite.com/login?userid=matt&password=123Caps that’s a problem too. Remove these parameters in the URL by converting from HTTP GETs to POSTs.
Once we have the front door defended, it’s time to think about the rest of the castle: Defending the walls from siege weapons, catching the folks who sneak in at night, and so on.
Sometimes the attacker skips the front door and tries a brute force attack. In the dark ages, these were catapults and siege weapons. On the Web, the bad guys loop through a sample username/password file, send a huge number of simultaneous requests to choke the web server, or try different directory combinations, searching for a directory that provides a file listing.
Some modern Intrusion Detection (ID) tools also function as a firewall, and can recognize those requests, take note of the IP address, and stop serving responses. Most of these solutions involve a physical appliance that processes requests in real time without significantly slowing down the network. Vendors like SonicWall sell appliances that serve this need, but you can build your own ID appliance using Linux and open-source tools.
Higher walls make pushing away the ladders a whole lot easier.
A Second Keep and Boiling Oil
No matter how high the wall or well-defended the gate, if what is inside is valuable enough to justify the effort, it is always possible for a bad guy to sneak in. In that case, you want to keep the bad guys (who now have access to the web servers) away from the rest of the data center.
The most common way to do this is to isolate every non-web-server machine behind a second firewall. You can also deploy intrusion detection behind the firewall to detect common bad-guy actions, like changing system files that should not be changed, or gaining access to other internal systems. There are plenty of free IDS tools; with a little effort you can set up one of them to email someone (and perhaps write an exception to the log) if they find anything.
By now you get the basic idea: Make it hard for the bad guys to get in, make sure they can’t get in, then detect (and torture) them when they do get in. (Boiling oil sounds so appealing….)
Find Holes in the Architecture
Imagine capturing the castle’s architect, pinning him to a wall, and asking him to reveal all the weaknesses of the castles he designed.
Today any public user can type in a domain into www.builtwith.com to find out any out the software architecture. For example, I typed in the URLs of two popular websites, and found out that they were built with WordPress – the first running Apache, the second with PHP, nginx, and jQuery. A Google search finds me a huge pile of known security issues in WordPress; if I were bound and determined to break in, the information is easily accessible. It doesn’t take much for a slightly sophisticated cracker to loop through a list of domains to find his favorite vulnerabilities, then automate some attacks.
Most vendors and open source projects repair security holes within days, if not hours, of the vulnerability’s discovery. Most of the time we can repair these back doors by upgrading software to the latest version. Builtwith tells us what the bad guys will know the most about, but it’s healthy to upgrade and patch all our software.
The challenge is not in the one-time fix, but in keeping applications current. Too often, however, we deal with consulting clients and employers that are less than conscientious about patches and upgrades.
In addition to the physical architecture of the castle itself, the castle lord needed to worry about the enemy. A rival king, the Normans, and those pesky Vikings all used different tactics, and might justify more serious countermeasures. Then again, they might not: Money spend defending against an attack that never came was sort of a waste.
In the 21st century, we need to think about the environment in which our applications live. If the bad guys get our data, what is the worst they could do? The scarier the answer (credit cards! social security numbers!) the more important it is to defend the data.
If the information is critical, it’s worthwhile to build another layer of protection. It might be a second keep, inside the first, with its own firewall. Perhaps we use a hosting company that promises in blood to keep our servers patched. Perhaps we worry about access permissions and roles with the customer service group.
York castle as it existed in the 14th century. Safe from cavalry; boats, not so much.
The technical term for this kind of work is hardening a system. There are plenty of guides to harden major systems for operating systems (from Windows to Linux) to databases (such as Oracle and DB2), both as online resources and as commercial books. The online sources may be more up-to-date, but make sure you know they come from a trusted source, like the Crosswalk from the Center for Internet Security (CI). The experts at Maven Security offer a free web penetration testing tutorial called “Web Security Dojo.” The Dojo combines several open-source tools and runs in a sandbox on any machine.
Once you improve your web application’s security, be sure to test to ensure your hardening actually worked.
If you choose not to, don’t worry.
Someone else will.
- Don’t Let 3rd Party APIs Fly Under the Radar
- Practicing Safe Sex with Third-Party APIs
- The Biggest Changes in C++11 (and Why You Should Care)