A Project Approach to Securing Web Services

Archive for January, 2008

A Project Approach to Securing Web Services

Posted by

Last week, I sat down to a project meeting. The project is implementing Sharepoint 2007. As I looked over the sprawling Gantt chart, one thing immediately struck my attention. No security tasks!

The first objective in securing web access is to get security integrated into the deployment project plan. The second objective is to get regular security reviews integrated into the change management process. That way, you can be reasonably assured that the system goes in secure and stays secure.

As a bonus, this approach means that security is not a roadblock but just another task. Often system owners and engineering want to avoid security review over concerns that it slows down the implementation. This can be avoided by baking it into the project. After all, a few hours pales when listed next to the hours the implementation team are spending. In this particular case, the InfoSec tasks are 48 hours out of 400, or 12%.

What am I doing with this time? First, securing the OS and web server. For that, I am looking at CIS (Center for Internet Security) and SCW (Security Configuration Wizard) templates. I am also using IISLockdown to further tighten up the system. Second, following vendor guidance to secure the application. Microsoft has excellent whitepapers that detail their security guidance. Finally, I am testing the implementation. This means using tools such as Webscarab and the skills I learned from the SANS AUD507 course.

In sum, I think it is important that network administrators include InfoSec as part of their project plans and ongoing maintenance. InfoSec professionals should use this time wisely to check the OS, web server, and application. The first time around, we play the part of the architect designing the locked down building. The second time around, during maintenance, we play the part of the night watchman, rattling the doors to make sure they are still closed and locked.


Related Links:

Center for Internet Security


Security Configuration Wizard


How To: Use IISLockdown.exe


100% Processor Utilization on Windows Backup

Posted by

Here is an odd one for you. I was backing up my notebook today ahead of Dell’s replacing the mainboard. My notebook computer would not launch Ntbackup. The process spikes the cpu to 100% and then hangs. I let it sit as long as thirty minutes and the process never releases.

I did some research. See that this problem is fixed with Windows 2003 SP2 (which I have). Reinstall SP2. Reboot. Reapply latest hotfixes and reboot. Retry, same. Did the file actually get updated? Change directory to i386, which contains a slipstreamed SP2 version of Windows 2003. The file is exactly the same.

I run Filemon and open Ntbackup. See that it is getting stuck on website.zip. This is a malformed zip file that Shabbir sent me a few weeks ago. End task on Ntbackup. Delete the zip file and clear the trash. Re-open ntbackup. click the Backup tab. It works properly now. Got it!

2008 US Presidential Elections Predicted

Posted by

Hashing functions such as MD5 are susceptible to collisions. That is, someone can take two documents and tailor them such that the resulting MD5 hashes are identical. One group showed this particularly well by hashing documents that shows who will win the US election. The group made twelve PDF documents all have the same MD5 fingerprint.


Predicting the winner of the 2008 US Presidential Elections using a Sony PlayStation 3


Reading your SSL Web Traffic

Posted by

Consider SSL. The web client and web server exchange keys and establish an encrypted tunnel, which they then use to communicate over. The person sees the reassuring padlock and begins entering sensitive information such as credit cards and passwords.

Of course, the person could be sending quite a bit more thru that tunnel and no one in the middle would be the wiser. This makes it difficult to protect incoming and outgoing traffic against threats such as drive-by downloads and data leakage. The question becomes how to read the SSL traffic as it crosses our Internet gateways.

I have been looking at Microsoft’s ISA server quite a bit recently. One feature they offer is SSL bridging. Now the web client negotiates an SSL tunnel with the ISA server. The ISA server then negotiates a separate tunnel between itself and the web server. Then ISA proxies web requests between these two tunnels. The web traffic is unencrypted on ISA itself and therefore can be monitored.

Of course, this means that people cannot trust their sensitive information is actually confidential. But, I am sure someone will say, we trust our network administrators. True, yet consider this: Akamai also does SSL bridging on a massive scale. This company handles web traffic for a third or more of all Internet sites. If you are hitting Akamai during an SSL session, someone at Akamai is reading your unencrypted information.

The Return of MBR Malware

Posted by

My security awareness training began on 1997-04/08. That is when the company that I worked with, ISC, came down with a bad case of the Monkey.B virus.

At ISC, we used several boot repair floppies. Many of these I created myself. They ran batch repair jobs to handle minor things like diagnostics and system burn-in. We had no policy for scanning the boot floppies for viruses. Never really occurred to us, for some reason. Then one day — April 8th — I noticed that a client’s computer had suddenly began acting strange.

Over the next ten days, we realized that all of our boot floppies had been infected with an as of yet unknown varient of Stoned.Monkey. Both McAfee and Dr Solomons failed to recognize this varient. F-Secure’s tool did, thankfully, and we were able to recover the client’s machine. In the next few weeks, we paid housecalls to our clients … many of whom we had infected during our diagnostic work.

With that as a background, I found it interesting that rootkits have returned to mbr infections.

Excuse me sir: there’s a rootkit in your master boot record

Financial Information eXchange (FIX) Flaws

Posted by

FIX attacks. As a financial firm, we are heavily reliant upon the FIX (Financial Information eXchange) protocol for buy-side trade execution. Security researchers have identified several concerns with the FIX protocol. The primary concern for my firm is trade errors and trade delays. Much of my security infrastructure relies upon data encryption, protocol filtering, and traffic isolation. All of these mechanisms come into play with the FIX network, as each connection must be isolated and each trading partner secured separately.


J Wolfgang Goerlich





(Thanks to Nathan Ouellette for the email on this issue.)

2008 Security Challenges

Posted by

Happy new year’s! Here is a quick look at what the top 3 security issues to watch for in 2008.

The profit motive is driving two forces in the attacker community. First, attackers are getting sophisticated and better trained. Second, attackers are getting specific and focused. Consequently, watch for highly targeted attacks. These resist traditional signature-based protection because they are very rare and specialized. They bypass most of our preventive, detective, and corrective software controls. We are very vulnerable to never-before-seen attack patterns.

Attacks on application and driver software will also increase. As operating systems progressively improve security, attackers will turn to applications’ soft underbelly. Many application vendors are unprepared for this sort of unwanted attention. The same can be said of hardware manufacturers. Worse, while applications run in user mode, hardware drivers run in kernel mode. This means that a compromised driver gives the attacker full control.

So think targeted attacks against poorly written drivers. Now when we talk about operating systems, with software and drivers, we usually picture traditional computers. Yet this is quickly changing as things become computerized. Everything from printers to pacemakers is becoming fair game. Thus another security concern to watch is vulnerable embedded devices and equipment.

I am not suggesting the future will be doom and gloom. There are many improvements underway. As I mentioned, operating systems continue to evolve and are becoming tougher all the time. Look for anti-virus vendors to shift from code signatures and blacklists to other heuristics, such as behavior modeling and whitelists. Finally, though they are in their heyday now, look for botnets to shrink and perhaps even extinguish in the next five years.

Some things will get worse. Some things will get better. Yet one thing will remain the same: InfoSec continues to be the premier IT challenge.