Blog: audit

During a recent audit, we noticed one of the Internet domain names registered to the bank was displaying a website provided by the registrar (Network Solutions).  Upon discussing this issue with the bank, they told me they had registered the name because they use it internally as their Active Directory domain name and did not want anybody else registering the public name.  So the bank’s IT vendor dutifully registered the name, but did not do anything with it as far as pointing it to an existing bank website or an “under construction” site.  As a result the registrar parked the domain name and displayed an advertisement website.  The advertisements were for Gucci, Wells Fargo, Bank of America, etc.  The bank was not very happy when they found out their domain was being used to advertise other banks.

Recently an information security audit customer of ours lost a backup domain controller and contacted their network vendor to rebuild the machine.  The bank thought everything was in order until three months later when they were audited.  The audit discovered the old backup domain controller had not been rebuilt to be a backup domain controller again as well as no antivirus software was installed.   When the bank contacted their network vendor, the bank was told there were some issues the vendor "meant to get back to".  Regardless of errors assigning roles for the domain controller, the vendor still should have installed antivirus and other applications requested by the bank. 

The reason why steps were missed? [more] No equipment recovery checklists had been created in the bank's Business Continuity Plan (BCP) so the vendor didn’t have a detailed list of steps to take in order to recover.  This can lead to both lost time and missed steps when rebuilding equipment.  Ensure equipment recovery lists exist for critical components of your infrastructure.

The Federal Financial Institutions Examination Council (FFIEC) issued an updated Retail Payment Systems Booklet.  The booklet is part of the IT Examination Handbook series and provides guidance to examiners, financial institutions, and technology service providers (TSPs) on identifying and controlling risks associated with retail payment systems and related banking activities.  To download the booklet and associated workprogram, visit http://www.ffiec.gov/ffiecinfobase/html_pages/it_01.html

In a recent information security audit, we noticed an inordinate amount of broadcast HTTP traffic - primarily from one XP workstation (traffic to/from an external address owned by peak10.com - a hosting organization).  We looked again to be sure we didn't have any rogue hubs in the network and then asked the bank about the situation.  After we gave them the specific workstation name and address, they discovered a user was listening to streaming Internet radio.  They then had to look into why their Internet content control wasn't blocking like they thought it would.

The interesting part of this is the fact the traffic was being broadcast throughout the whole branch network rather than just her system.  Of course, the Internet bandwidth consumption would normally be of more concern than the local network traffic.  However if there already had been a problem with the LAN, this could have made it worse.

The shredding of printed information is an important part of information security.  It's important to use a cross cut paper shredder as apposed to a strip cut shredder, but most of all it's important to verify that all your printed information is being shredded before it's thrown away.  [more]

During a recent audit we had a client tell us that they collect all their paper to be shredded, lock it up daily, and then send it to one of their main branches for shredding on a weekly basis.  It's our standard procedure to check the dumpsters behind our customers during our audits and in this case we found a few trash bags of non-shredded paper containing customer information. A trash bag full of paper with customer information appears to be regular trash to the untrained janitorial staff.  In this case proper labeling and more training could have helped avoid this problem.  Taking the time periodically to ensure that your paper shredding procedures are being followed could prevent exposing your confidential information.

While onsite for an IT audit this week, I had to connect to a bank's network from three separate locations. 

At the first location, I got a couple of DHCP addresses (one for my host and one for VMWare workstation) and had no trouble getting connected to the Internet (via browser, RDP, etc.).

When I connected at the second site, I was able to get Internet connectivity from my host but not from within VMWare.  I fiddled with it for a while and finally made do.

When I connected at the third site, they told me they needed to give me static IPs since they had IP tables in their Checkpoint firewall to define what systems had Internet access.

That got me to ask why I had no problems at the first site and half a problem at the second site.  The root cause of all this was their lack of reviewing the IP table in their Checkpoint firewall.  The whole bank subnet at the first site was allowed access to the Internet (this was leftover from a merger about six months ago).  The IP address DHCP gave my host at the second site just happened to be in their list on the firewall (nobody could remember why that random address was in the table).  It's good to review your configurations or have someone else look over them, because mistakes won't necessarily be obvious.