Perimeter defense is a lost battle.
Like old generals, we're still fighting the last war, in which our network was a castle with impregnable walls, a well-defined entry point across the drawbridge (head-end router), portcullis (firewall) and guards (IDS).
Today's infosec paradigm is submarine warfare. Attacks can come from anywhere, at any time. There's no well-defined perimeter, and it's often difficult to tell friend from foe. Defenses should focus on hardened, well-protected assets--not bigger, stronger fences. Stealth, intelligence gathering and deception play increasingly critical roles in enterprise security.
We have failed to adapt to the rapid changes in technology that have fundamentally altered the battle we're fighting. Instead, we continue to spend money on point solutions to counter the latest attacks. We need a fundamental change in thinking--not just more layers of firewalls, IDSes and network components. We're simply fueling an infosec arms race, in which the only victors are the arms suppliers.
The submarine warfare model teaches us that there's no viable perimeter--the enemy can be anywhere.
In this article, we'll show you a half-dozen ready-to-use "combat tactics" suited for submarine warfare, the new information warfare paradigm.
Danger is everywhere
The submarine warfare model reflects the fluidity of your enterprise environment. The castle model assumes a single, well-defined entry point, but your organization has hundreds, even thousands of openings: point-to-point connections with partners, vendors and even competitors.
Employees and consultants open still more holes--from the inside. Dozens of modems litter your network; users bring in wireless access points; consultants unplug fax machines to obtain analog lines to dial up their corporate LAN from their network-connected laptops. Employees connect their personal machines to your network, despite the fact that those PCs are largely unpatched, virus infected, owned and/or filled with adware and spyware. Over time, your firewalls start to resemble Swiss cheese, as business partnerships require more and more ports to be opened, while unnecessary ports often remain open long after they're needed.
We have a lot more to worry about than barbarians at the gates. The submarine warfare model teaches us that there's no viable perimeter--the enemy can be anywhere.
Just look at what's happening on your network:
- Roughly 75 percent of attacks come from the inside, not the Internet (excluding repetitive worms).
- "Trusted" employees load KaZaA, GoToMyPC, Gnutella, HTTPTunnel, IM clients and other P2P applications on their workstations, blowing hundreds of virtual holes in your perimeter.
- With the advent of Web services, you can't presume that your core networks are trustworthy. XML and SOAP are now tunneling Remote Procedure Calls (RPCs) through your firewalls over ports 80 and 443. They're connecting the Internet to your core business applications and databases.
- Web services moves application servers to your outermost DMZ, requiring the same servers to provide both presentation and application layers. These mission-critical servers are simultaneously terminating Internet connections and executing business logic, opening your enterprise to greater risk. Fortunately, some Web services vendors are well aware of this issue, and are taking steps to resolve it (see "Tightening Web Services Security").
- Web services essentially provides a way for your developers to publish RPCs to the Internet, but change control and code review get short shrift in the rush to bring Web apps to market. If major software vendors producing shrink-wrapped software continue to publish RPC vulnerabilities, despite rigorous code walkthroughs and change control procedures, imagine how many RPC vulnerabilities your Web developers will code into their Web services apps.
Small wonder that firewalls no longer mount a credible perimeter defense as a single-point solution. It's time to implement the following six courses of action and bring your infosecurity tactics up to date.
1. Divide and Protect
"We have met the enemy, and he is us." --Pogo
The down-home wisdom of the old comic strip character is dead-on for contemporary enterprise networks. Why is your core network considered trusted, even though most attacks come from inside your network? In particular, why is IT development on the same subnet as production servers?
To protect the assets of the company, your core network should be considered a DMZ, and should be segmented (see Figure 1). This approach provides a low-cost way to segregate your core network into trust zones and limit virus and worm outbreaks. Segregate and firewall high-value subnets, such as finance, HR, CIRT/security operations and R&D. Intranet applications provided by these groups, such as an expense reimbursement application, should be hosted in the core production network. Treat these intranet servers as production servers, with appropriate change control procedures.
Strict segregation of systems and clearly delineated change control is particularly important for IT development. Except for application support, there's rarely a business need for programmers to have access to production servers. Otherwise, you have a huge gap in change control, which will result in unauthorized production changes. Even more to the point, since most virus and worm infestations start in development networks and test labs--where there's typically no patch management or change control--it's foolhardy to have them on your production network.
Consider the experience of a startup finance company undergoing rapid growth. The company was plagued with database failures, corruption of data and database server crashes, most of which went unexplained. After several incidents caused embarrassment with customers and significant expense, the operations team was allowed to revoke database logins for developers. Although the exact causes of these problems were never found, most of them evaporated after all developers were locked out of the production servers.
The lesson? Use change control to create a "code firewall" --segregate development, test, production and disaster recovery into separate networks, spanned only by network admins and change control teams.
With a code firewall, no one should have the ability to promote code from development to production. Network admins should be able to traverse both networks, but shouldn't have access to source code libraries. Developers with access to source code shouldn't be permitted to traverse network boundaries. Similarly, application-based production support personnel shouldn't have privileged rights in development, nor access to source code, since that can easily subvert your change control.
Production support staff should work closely with developers and server teams to request changes to source code or configurations, but shouldn't be permitted to make the changes themselves. With these controls in place, it's far more difficult for application support staff to commit fraud or build backdoors into production systems.
2. Harden Everything
There's no such thing as a truly trusted zone: hardening DMZ servers simply isn't adequate. Since all your systems are open to attack, you should harden all of them. This includes all test, development and intranet servers.
Six 'submarine warfare' tactics
1. Use internal firewalls and change control to segregate trust zones and separate production and development.
2. Harden all servers and workstations, not just DMZ servers.
3. Confuse and mislead the enemy. Lure and trap him.
4. Drill your teams to produce a high state of readiness and security awareness.
5. Adopt a zero-tolerance stance for rogue servers and hacker software on your network.
6. Employ asset management to protect critical components and expend resources efficiently.
All workstations and servers should have minimal installs. Workstations should be protected so that most users can't install software or change configurations. Kiosks and walk-up terminals should be particularly resilient and hardened.
Call me a Luddite, but most clerks and customer sales reps can perform their jobs efficiently with a green-screen terminal, so why help virus writers and hackers by giving these employees general purpose workstations? Where possible, limit multipurpose operating systems and tools like Office and Internet Explorer to those workers who really need them. Clerks, help desk technicians and call center staff will be just fine with smart terminals or thin clients.
Of course, hardening every box on your network is a pretty tall order--more than most organizations can afford. Practically speaking, you'll probably only have the resources to completely harden new and replacement units, and will achieve full-system hardening through attrition. However, don't ignore the rest of the nodes on your network. Wide-open default installs on a few lab servers are an unacceptable risk, since they endanger all other components.
You probably can afford to take incremental steps across the board. Let's look at a real-life example.
Long before enterprise and e-mail antivirus systems were prevalent, I worked for a company that was having problems with viruses infesting our network. Several employees were installing games, rogue software and "inappropriate material" on their PCs. (This was before the company was connected to the Internet.) The approach of our network team was simple. In a single evening, we disabled the floppy drives on all PCs in our company, removing their cables and locking down the BIOS with passwords. We also swept through and removed all modems that were outside the data center, since they weren't really being used for business purposes. We left two PCs with floppy drives, and a single PC with a high-speed modem, all of which were locked in the data center.
In that single, short project, we eliminated all uncontrolled data ingress/egress points in the network, and our problems with viruses and rogue software were eliminated. The world has changed since then, so that approach is obsolete, but the lesson is still valid: An incremental improvement in security across all PCs creates systemic changes that far outweigh the benefits of drastic improvements on a handful of PCs.
You can get significant traction in hardening your network against attack by developing an OS-specific security checklist of 30 to 40 steps, and performing these on all servers and workstations. Use the same "quick hit" approach for switches, routers, firewalls and hubs. Spending 10 minutes improving the security posture of each box will significantly improve your network defense, and give you breathing room for a gradual rollout of hardened PCs.
3. Confuse and Mislead the Enemy
No one tries to hide a castle--fortifications are flaunted to impress enemies with your strength and discourage attack. Instead, the submarine warfare model teaches us to confuse and harass attackers, and hide from them when possible.
Cyber defenders can use a number of tricks to confound the enemy. These steps are inexpensive and make your domain nearly impossible to scan:
Disguise your server OS and server load. Why advertise use of IIS by naming ASP scripts with an .asp extension? Instead, save all ASP scripts with .pl or .cgi extensions, so that script-kiddies will think you're running Apache and not IIS. Figure out creative ways to make Apache look like IIS, IIS look like iPlanet, and iPlanet look like WebSphere. There are several good Linux and Unix tools that will emulate a particular flavor of *nix or Windows; you can use a few of these to point script-kiddies in the wrong direction. These tricks won't fool sophisticated attackers, but they will confuse the enemy, and may very well help you dodge the next hybrid worm. No, security through obscurity isn't a complete strategy, but it can help deflect simple signature-based attacks.
Use bogus ports to "scan-proof" your network. First, open ports 20, 21, 23, 25, 37, 42, 43, 49, 67, 68, 69, 80, 109, 110, 137-139, 389 and 443 on all Internet-facing and DMZ servers by running a bogus "listener" on these ports, such as @stake's netcat. Configure these listeners to forward packets to an IDS for all connection attempts. After all, no good guy is going to try to connect to a Telnet port on your Web server. Once bogus ports are operational and linked to an IDS, you can fight back by loading LaBrea, a cool utility that halts scanners and script-kiddies in their tracks by hanging their scans.
Use honeypots to mislead attackers and reinforce your IDSes. If you use NAT, you likely have quite a few unused IP addresses available in your public registered domain space. Why not set up honeypots, such as Honeyd, to monitor all the empty addresses in your Internet-facing DMZ? The honeypot server can emulate all the other servers as "ghosts" that listen on the other 65,000 unused addresses in your address space.1 Then configure all legitimate servers to have the same ports open as the honeypot, so they'll all look the same to a hostile scanner. Any connection to an address other than your advertised services is likely to be hostile traffic. Meanwhile, an attacker will see 65,000 targets instead of, say, 30, and will have only a minute chance of hitting a "real" server with his attack.
Even more to the point, the attacker will almost certainly trigger an alert. Forward all bogus contacts to IDS sensors, and you'll have an elaborate tripwire system that costs about $2,000 to implement in most environments. By the time an attacker locates a legitimate server, you'll have logged and analyzed hundreds of penetration attempts and may be able to thwart the attack before it can do damage.
There's some risk in this approach, because it means opening a ton of ports on your firewalls, but remember that the enemy isn't always on the outside. Take a deep breath, and remember that you don't really have a perimeter any longer. Once you're listening on 50 ports across 65,000 hosts, most of your firewall's processing will be spent blocking Trojan and worm ports (e.g., 4156), and your firewall will no longer be providing useful information to attackers.
4. Hone Your Combat Teams
Submarine warfare requires a highly trained and motivated crew, and network security is no different. That means everyone, not just security staff.
Assemble "blue" and "red" teams made up of DBAs, architects, network and system admins, business analysts, developers and help desk personnel for a weekend of "capture the flag" war games in a lab environment (with plenty of Red Bull handy, naturally). While red teams attack systems, the blue teams analyze and learn from the attacks, and patch the vulnerabilities. Conduct a debriefing, perform root-cause analysis, and then switch teams. As Bill Cosby would say on "Fat Albert," "If you're not careful, you might learn something." Imagine the depth of understanding your developers and business analysts will have in building secure systems once they've been through this kind of exercise.
5. Eliminate the Enemy Within
Submarines impose strict security rules on their crews. Your organization should enforce infosecurity with the same rigor. If there's zero tolerance for drugs, weapons and child porn in your workplace, why should rogue servers and hacker software be treated differently? At a cost of $75 for wireless access points, employees can easily create a backdoor on your network. Rogue servers probably won't be patched and are likely to propagate worms on your network.
If search and seizure sounds a bit Draconian, remember that you're responsible for your organization's security. However, don't just storm the cubicles with your saber flashing. First, cover your backside by getting management support for a zero-tolerance policy. Work with legal and HR, and then announce that installing hacker software and rogue servers will carry the same consequences as a handgun or crack vial. Empower IDS and compliance groups to alert CIRT when rogue servers are discovered, and seize them.
If search and seizure doesn't mix with your enterprise's political culture, simply go to the wiring closet and disconnect the rogue device from the production network. Justify your actions by citing lack of change control.
6. Your Assets Are on the Line
Since we can't depend on perimeter defense to protect our assets, our defense model should focus on the host first, spiraling outwards through distributed systems and networks. Look to the real world for asset protection models. Car dealerships don't shine floodlights on the back fence, but rather on the cars in the lot. Banks concentrate on protecting vaults and cash-handling systems, not the front door or parking lot.
We don't have the budget or resources to protect all our assets equally or all at once, so sound asset management is crucial to the defense of mission-critical systems. It boils down to three basic steps:
- Start with asset inventory. Perhaps your network team, configuration management group or even your old Y2K asset databases can provide much of the information you need. If you're lucky, this won't require an actual inventory, but simple reconciliation of existing data sources.
- Map your assets to their business functions. How else will you quantify the system's value to your organization? Your map should be as granular as possible, down to the individual servers and network components. Your disaster recovery team should be a big help: mapping business functions to assets is a core competency for them.
- Prioritize those business functions through business impact analysis (BIA). Again, the DR folks will be able to give you a good start. Work closely with your business managers. They understand the impact of a downed or impaired system: Will the company newsletter be unavailable on the intranet, or will your customers be unable to do business online?
Once you understand the business value of your assets, you can classify and prioritize them--let's say A through D--as security risks (see Figure 2). For example, "A" servers will get critical patches first, then B, C and D. Class D servers won't even be patched for low- or mid-level threats, since that's just expending valuable time and effort that should be spent on your A systems. In the same way, you can prioritize CIRT, redundancy and fault tolerance systems, disaster recovery, server hardening and other security activities.
The Battle Is Joined
By employing new ways of thinking about perimeter and network defense, we stand a real chance of winning the war, but only if we abandon the arms race and adopt a new paradigm for thinking about our perimeters.
Most of these changes don't require significant resources, but depend on allocating resources differently. Even some of the more expensive measures, such as hardening all servers and workstations, will likely pay for themselves through reduced help desk and support calls, even if you can't show a hard security ROI.
We can no longer conduct business as usual in a futile attempt to patch a perimeter that has all but disappeared. Submarine warfare teaches us that the perimeter we must defend is the hull of the ship (the host machine), and the enemy can strike from anywhere. Good hunting!
Dan Houser, CISSP, SSCP, is a senior security engineer for a Fortune 500 financial corporation.