September 6th, 2006, 01:52 AM
That was a stressful couple of days but a good learning experience as well. As pointed out by Nihil they were very keen on physical security and impressed by the brand new dead locks on the computer room etc.
In the end they had to ask for an Administrative account as their scanners could penetrate our network and then we had to turn off SP2's firewall on the MS boxen. Very happy with that.
Nessus was the scanner for the Linux platform as expected and that worked in our favour as we use that on ourselves from time to time to see where we're lacking.
Once they'd scanned all of the networks they put out a preliminary report and our network got a pat on the back for the firewalls and also port security on the switches.... Not a bad result so far, now to wait for the full report....
Thanks to all who contributed to this thread. Now to update all of the policies that this process has highlighted I'm missing.
September 7th, 2006, 06:46 PM
I haven't seen it mentioned, but I'll be honest and say I didn't read every response.. But shouldn't your security policy tell you exactly what they will be looking for? I'm not sure why you would have to go all over the internet figuring out what kind of security you should have when your policy should tell you exactly that. If you don't have a detailed security policy I really wonder how you can complete an audit. How do they know what to check for?
I have complete security audits run every month against several of my machines, these consist of weekly automated checks, monthly internal machine configuration checks, and monthly physical access checks. I never get worried about it because I know the policies and I'm following the policies. Are the machines locked down as tight as they can be, no.. but the policy doesn't dictate that they be any more secure than they are for the data that they have. To me a security audit is like an open book test in high school where you were given the questions two weeks before the test. You should know what they are looking for and should be able to insure you are 100% compliant well before the auditors arrive. I do agree with the other folks that this is not something you should be trying to scamper to fix 30 days prior to an audit. You should be doing it all of the time.
IT operations should have access to the same scanning tools that the Security organization has access to so that proper testing and configuration management can be performed at all times, not just when you are undergoing an audit.
September 7th, 2006, 07:33 PM
some audits, like Visa PCI don't care too much about your policies (well this is a qualified statement, merchant PCI is one thing and service provider PCI is a different beast all together). While they will test that you are indeed meeting your own policies a lot of audits will go outside of that scope. When I was working in the financial world the FDIC and Visa would regularly conduct their /own/ audits of us that had little or nothing at all to do with the mechanisms that we had in place already.
One little snafu I recall is that we were encrypting data sent from our application servers to our database servers but we had a "weak" key management system in place. We were following our own policies which were fine for stuff like SAS70 audits, internal audits, etc, but when Visa hit it they weren't too pleased with it. They required us to use HSMs to secure the keys.
So while were were good based on our own baseline, and previous audits, we were dinged pretty hard by an external audit that wasn't testing our policy but /their/ own policy against us. A lot of gov't auditing is the exact same way.
Oh and fwiw Visa gave us no heads up as to what to expect from their audit. Trying to get info as to the audit requirements for Visa PCI is like pulling eye teeth, unless you know the "right" people.
Give a man a match and he will be warm for a while, light him on fire and he will be warm for the rest of his life.
September 7th, 2006, 10:08 PM
I think that it is a good thing that they didn't know exactly what the auditors would be looking for. If someone was actually going to try to break in to steal information, I don't think they would call up the organization and say, "OK, I am going to try to break in, and this is how I am going to do it... " I mean what is the point of doing the audit then. I think that even telling him a month in advance was nice of them. Security practices should be followed closely every day, especially when you are working with sensitive data. Just my thoughts on the subject, I could be way off.
\"Those of us that had been up all night were in no mood for coffee and donuts, we wanted strong drink.\"
September 8th, 2006, 03:52 PM
I completely disagree. If you are doing work for Visa, then they should tell you what they expect from the get go. The purpose of an audit is to make sure you are following policies or to correct problems in the policy. It isn't to try and suprise you with things you never thought about.
We do a lot of work with american express. Every system that has anything to do with american express follows our corporate security policy as well as the specific machine policies that were created for those machines by our corporate security department and some security people from AMEX. When they are audited they use the agreed upon security policy. Nothing else. Our policies, as most should, even define how the audits will be conducted.
And without a complete policy how do you do that? Just go on the best effort of the administrators? I don't think so.
Security practices should be followed closely every day, especially when you are working with sensitive data.
Everytime I have ever worked with a government agency or any type of financial firm their security policies were always made very clear from the start. I can think of one audit where we were dinged for several items that were added by our customer to their security policy. When the final report came out as to why we were not following that particular piece of the policy the blaim, and subsequent corrections, were made to their communication process. They had never ok'ed those changes with our security organization, and they never told us.