I'll throw comments throughout! > > I currently work at such a financial institution, a credit union. > Modifications to our home-banking product were frowned upon, partially > because the product vendor created such a touchy product that any > change might break things. They built a customized IIS 3 web server > that was vulnerable to the CGI double decode vulnerability (and > probably a lot of others) and Microsofts patch broke the system, > perhaps because they were running an ancient IIS 3. Well, this > increased the heat on the vendor, in thanks partially to my > conversations with an engineering manager. Within two weeks they > had upgraded the system to IIS4, applied SP6a + post hotfixes > and other security patches. In that two week period, probably every > single institution (except ours) using their product was wide open. Perfect. This is what the article was attempting to say. (maybe not as concise) FI's are in my beliefs a little to trusing of 3rd party vendors, and the technical ability of the FDIC, OTS and OCC are not strong enough to prevent the above issues. The letter that your regulators require can come from a 1 man security operation. All it takes is the vendor of the application to contract a small security agency and woola, they are providing a secure product. This is not what the financial industry needs, we / they need all regulatory agencies to provide stronger measurments against security. > The intersting thing is that following the standard IIS security > guidelines locked the box down with little trouble. I revoked the > permissions to /winnt/system32/ for the IUSR account, which prevented > attackers from launching cmd, tftp, net, etc and other commands. I > also removed the Win NT challenge/response authentication method from > the webroot since this would then give attackers an opportunity to > brute force accounts through a password dialog box. And of course, > account lockout was not set by the vendor, along with EVERYONE > Full control on both C: and D: drives. My supervisor discouraged > me from making any change to the system for fear that it might > break. Thankfully, action was taken that blocked an attacker > that very night. Very, very sloppy on behalf of the vendor. Sounds like a bad recipe to me. This is actually very common. I have built several recipes for FI production deployment and they were as secure as they get at that instant. Then tomorrow, the next week, month, year and so on they were still using it. Thats just no good. > I suggested that the vendor undergo a code and security audit > before releasing it's products, as well as looking at some > products like eEyes SecureIIS app level firewall. The incident > spoken of here lit a fire under them, which increased the speed > at which their QA and security committee began to take things > more seriously. However, no mention of this issue was to be > found at their recent annual users meeting. Brush it under > the rug perhaps? Well, I can't blame the company for not mentioning it to the public. Thats just plain suicide, but I have witnessed several malicious hacks, even data hostage situations that 1 particular vendor covered up very well. But again. <let me know if you get tired of hearing this> FI's need stronger security regulations. > A compromise of the NT/IIS server mentioned here would not give > attackers an easy means to actually perform funds transfer, > but they could trojan the system through tftp, pilfer account > numbers from log files, and obtain a lot of data, including the > administrator and other high-level passwords from an > EVERYONE FULL CONTROL batch file that added administrator and > three hardware support accounts (one of the passwords was > "eatmeraw" which I found amusing, since their security > mechanisms did indeed suck). Very very sloppy........ If I remember correctly this might be the same vendor that thinks disabling packet forwarding on an NT box with 2 NIC's saves the internal network from being hacked. > >From discussion with others on this issue, I gather that many > internet banking sites are very exploitable. You would think > that something this sensitive would receive better attention, > but I suppose that security professionals have their work cut > out for them in the forseeable future. The market is growing very fast, and a sensible balance is hard to achieve. We all know that security does not work alone. If you had a solution that was 100% secure, nothing could ever be accomplished. So what you end up trying to do, is creating a perfect balance between security and functionality. Then everyone will be happy. (hopefully) > Credit Unions in particular are coming under fire with a > new batch of National Credit Union Administration (NCUA) > regulations, including penetration testing, use of network > and host IDS, security audits, and compliance of outsourced > vendors to certain standards (such as standards covered by > something like the reputable TruSecure certification). > A welcome event, which is bringing more business to the > security community, as these institutions often don't have > the in-house expertise to stay abreast of the fast-paced > security landscape. I agree completely, the TruSecure Cert, and the WebTrust Cert are what FI's need. Although I have witnessed an FI that recieved a TruSecure Cert and truly was hurting for policies and procedures. But, there are always going to be the ones that slip through the cracks. Thanks for the information. Kelvin.
This archive was generated by hypermail 2b30 : Mon Jun 25 2001 - 06:13:48 PDT