roviding a service on the Web entails a wealth of concerns, from system design, network architecture, and application development, to maintenance and security. This last aspect is often overlooked and undervalued because proactive application, system, and network security offer little tangible return. Not until a Web service vulnerability causes loss of money, damage of reputation, and loss of customer confidence does security rise to the fore.
Building and maintaining a strong security environment has two primary phases: initial deployment and ongoing maintenance. The initial deployment is much like building a Middle Ages castle. The defenses for these stone fortresses were not just a wall or a moat but a study in the concept of “defense in depth” with a series of security controls intended to thwart attacks. Most castles had a series of inner walls in addition to their primary outer barriers, which allowed for a controlled retreat into a layered defense. Like the castle, a secure Web environment should be designed to control the movement of malicious, or potentially malicious, persons and slow any attacks that manage to breach one layer of defense.
The second major aspect of security, maintenance, is often neglected because it requires sustained vigilance. Take the castle once again. Without guards in watchtowers, locked gates, and constant vigilance, the walls, moat, and other defenses can be useless. If the drawbridge is left down, or worse a side gate left unlocked, the attackers can simply bypass the wall defenses all together.
Now, consider your environment. You have hardened your servers, configured your routers, and patched all known security vulnerabilities. Your castle is secure and all the doors are locked, so you and all the guards sleep soundly. But is your environment secure? Of course not. If all the systems administrators, network administrators, and application developers don’t keep a watchful eye, your castle will be overrun as soon as an attacker finds a way to bypass all those defenses.
To design secure Web services you must not only build a secure environment but also maintain a strong security stance. One without the other is of no value.
Check It—Constantly
Although occasional checks and fixes provide a relatively strong barrier against known attacks such as worms, viruses, or the latest directory traversal, more insidious attacks often will test the defenses of your Web services. These attacks are often quite dangerous because they rarely are noticed during the course of normal business and are stealthy enough to slip past inattentive network and systems administrators. Maintenance, then, is not merely applying the latest hotfixes and patches, but a frame of mind. Logs are culled for potential signs of danger, port scans and probes of network security are not set aside as unimportant, but instead are monitored and investigated frequently.
Maintenance is one percent applying patches and access control lists (ACLs) and 99 percent vigilance in monitoring, log examination, and traffic-pattern analysis. In short, it can be very dull. However, this vigilance is far more important than building a secure Web service alone. Even if a service is insecure but a vigilant administrator, engineer, or developer monitors its activity, the chances of an attack succeeding are dramatically reduced.
Managed Security Solutions: The Cure for Security Tedium
The most tedious and mind-numbing aspects of the security work, culling log files, performing traffic analysis, and monitoring application and database access, are the most important. So how do you assure the peace of mind of having a secure, well-maintained environment without culling through the proverbial haystack to find a vulnerability needle? Well, this is where managed security solutions (MSS) come in handy.
Managed security solutions will make the jobs of traffic-pattern analysis, log file parsing and examination, and application-use mapping much easier. Security utilities such as WebTrends, Netsaint, Tripwire, Stealth Scanner, and Whisker (see Web Server Scanners: Find Your Vulnerabilities Before Hackers Do), which can be integral parts of a MSS, provide assistance in the aspects of maintenance so often missed by even the most diligent systems, network, and application engineers.
You can design an MSS in-house, outsource it to an MSS provider, or adopt MSS third-party software. The design documents from the initial phases of your Web service construction will help to define your requirements for an MSS. If, for example, you have a very small Web farm with load balancers and only a small Internet-facing presence, perhaps a MSS that performs network assessment primarily and server and application assessment secondarily is not the most fruitful way to go. If a large network presence surrounds your server farms but the farms are well controlled and maintained by an army of systems administrators, then your ideal MSS will focus on the network and application. Footprinting Verifies Strengths and Weaknesses
You can use several methods to verify the security of your Web services and the environment in which they run. These methods entail a strong understanding of the application, the systems, and the network, and if done properly will provide an overall view of the security posture surrounding each aspect of the Web service.
Footprinting, the process of gathering data regarding a specific network environment, provides a snapshot of the entire Web service environment’s security posture. By the environment, I mean not just the application, the network, and the servers, or the patch levels, hotfix levels, and service-pack levels, but all of these things and more. For example, footprinting often will detect that rogue Web server in the marketing department running an unpatched version of the OS, Web server, or application server, an inviting target that could lead to a compromise of the primary Web service platform (depending on trust issues within the corporate network environment). (see Build a Managed Security Solution for Your Web Servers with Open Source Tools for a guide to footprinting with open source scanners.)
Footprinting also will show the state of the network, the routers, and the ACLs that surround the applications and servers. Do these routers allow access to the internal network if a certain TCP/IP source port is used? Perhaps DNS zone transfers are performed regularly, and as such port 53/TCP is allowed to enter into the network. These sorts of exceptions often are inroads for an attacker. By footprinting the environment regularly and making sure to examine the results, the chances are much higher for someone within the organization to discover that rogue Web server or notice that anomalous traffic before an outsider breaks through the defenses.
Build It Right the First Time
Let’s look at a simple example of a Web application architecture and its surrounding infrastructure: online stock trading in the nascent design state. The systems engineers and administrators decide on a platform, operating system (OS), and Web server. The network engineers and administrators decide on a network architecture and infrastructure. Finally, the application developers develop an application to utilize the system and network architecture. Initially, the systems engineers and administrators design a secure platform for the software. Realizing the need for strong security, they apply all available service packs, patches, and hotfixes as part of the system design specification and configure their servers and software to secure the platform at an application server level.
In tandem with the systems engineers, the network engineers design a secure network architecture that will meet the needs of the business. This architecture also incorporates patches and hotfixes for the network hardware, and includes configuration changes to control the flow of traffic between the inside and outside networks. The network is now secure for traffic to flow to and from the servers.
Finally, the developers design a secure application. They perform proper input validation, manage sessions in a viable, secure manner, and use encrypted transport mechanisms. Moreover, they place no trust on the client, a practice in application design that leads to many pitfalls.
If any of these three aspects were designed poorly: a hotfix missed, a router not configured properly, or an error in application development allowed the use of clear-text protocols, then the entire design’s security will fail.
