Yours is an interesting opinion, but there is no evidence to support it and there are no guidelines in either SOX or CORBIT 4.1 that support it either.

For example, you mention Check Point or PIX and then ISA behind them. While this is definitely the conventional wisdom in the “hardware firewall” world trained by Cisco sales reps, there is definititely no support for this supposition in either SOX or CORBIT.

In fact, if you understood the ISA Firewall, you would use it as a front end domain member server in many scenarios where the “auditors” have fantasized that it shouldn’t be done. When you confront these auditors, they can provide NO EVIDENCE regarding their opinion.

In contrast, we’ve proven that domain membership for the ISA Firewall actually enhances SOX compliance based on actual working in the SOX and CORBIT guidelines. Now, there’s something you can take to the bank!

BTW — don’t use terminology like “opening domain ports” — it makes you sound like a “port opener” neophyte, which we know isn’t true. Check out www.tacteam.net/openport.htm

HTH,
Tom

You will have [always] to exceed the regulations in your setup.

ISA membership in the domain is dependent on the environment, in some setups maybe it is recommended like if you use ISA to manage user’s outbound traffic.

If you have an environment with two levels of firewalls lets say: Level 1-Checkpoint and Level 2 – PIX) and you have Exchange F-E resides internally, ISA server is put in the DMZ (between L1 and L2) to publish OWA,

To avoid opening domain ports for ISA, RADIUS authentication is used for OWA.

In this environment I think ISA being not member of the domain is more secure, off course you would have another internal ISA+WebFilters+..etc managing outbound users’ traffic.

Regards,

Nizar Shanaah

Yes, and much of it may be related to what Jim said — the compliance “testers” are also the ones who will benefit from costs of coming into “compliance”. There’s a built in conflict of interest there.

I think we need to put these jokers on the defensive. We’ll hammer on the SOX situation first and analyze the CORBIT 4.1 guidelines. I’m sure the CORBIT will say NOTHING about domain membership. That will blow a hole in the compliance tester’s OPINION and then they’ll have their hands forced to prove their other recommendations. I suspect that out of laziness and greed, they’ll relent on the domain membership issue if this issue forces them to defend their other marginal or just plain WRONG OPINIONS.

We’ll tackle HIPAA next.

Tom

You could have written a very similar post for any of the new regulations. Too many companies are being led down the garden path by compliance “experts”. These experts usually have cookie cutter programs to recommend under the guise of keeping you out of potential trouble. Unfortunately it ends up costing companies big money in the short and long run not necessarily because it’s that difficult to comply but because of the cost of implementing the experts recommendations.

One other aspect that I discovered last night - if the person performing the SOX testing is also providing consultancy services related to the client’s SOX compliance, then a conflict of interest is indicated and must be resolved.

IOW, the person who is hired to determine and satisfy any SOX requirement *CANNOT* be from the same company that was hired to provide the SOX compliance testing.

If your “consultant” offers to “validate your SOX compliance” while simultaneously “creating processes and security” to satisfy SOX requiements (they don’t have to be the same requirements), your SOX compliance is now at risk.

IOW, youcan’t use the same entity to both establish and validate your SOX compliance.