Sarbanes-Oxley

[Les Ligetfalvy]

Can anyone share how they use PCM+ to meet the requirements of SOx? I have the latest PCM+, but I don't see how I can easily generate the reports for compliance.

Please help.

[Kell van Daal]

Hi Les,

Could you provide some details of what reports you need for SOx? I'm not really familiar with it.
Maybe more people can help you then.

[Les Ligetfalvy]

That's just it... the auditors won't tell us what they need, they just point us to the thousands of pages of legislation. I was hoping someone had already sorted that bit out and would share it.

[Les Ligetfalvy]

Is it that nobody uses PCM in their SOX or that it is too painful to discuss?

[Matt Hobbs]

I had a brief chat to a friend about this who has gone through SOx auditing in the past. He advised that they will just want to see what security measures you have in place to prevent financial data being accessed by users that don't require it.

In the case of your network, ACL's I would imagine is what they would be most interested in.

Don't quote me on this though.

[Les Ligetfalvy]

Well, my network is around 50/50 legacy/Procurve so I am not using any ACLs at the network layer.

I was hoping to get by with just change management on just the Procurve equipment by using the configuration revision logging and reporting in PCM+.

I don't know how I am supposed to handle the change approval process because I approve all my own changes but SOx assumes that I cannot be trusted and must get approval from above. In reality, it is those above me that are not to be trusted.

I plan to declare the legacy half as unmanaged.

[Chris Sidwell-Smith]

We've just gone through SOX ourselves (though as a US owned UK company).

The auditors love documentation and paper trails.

The (rough) setup we use it.

1) Document. Switch config is documented.

2) Change Control. All alterations to switch config are documented and authorised.

3) Security. Only a the people that need it can access the switch config.

Now we are doing a followon project in investigating IPS/IDP but that is seperate from our Procurve switches.

Now if there are specific security/financial issues (say a financial VLAN or network segment) then generally they can be covered by the above.

[Bergin]

Just to add in my own experiences

1) Document. Switch config is documented. (And reviewed)

SARBOX is big about one person documenting, the another person reviewing what the first person documented and a third person approves it. You will see this idea of multiple people as a check/balance systems.

2) Change Control. All alterations to switch config are documented and authorised.

Same thing - One person initiates the change, another person approves the change, and one person does the change. See - multiple people.

3) Security. Only a the people that need it can access the switch config.

Read this - no more generic login's - no more Administrator, no more Root, no more Admin, etc.

All accounts must be me unique and auditable, they also must be only enabled when a change has been appoved, and only for the systems that are covered by the change package. Think RADIUS, TACACS+, daily reporting, etc.

Hope this helps

I would add this as well

4) Reporting - most SARBOX wants reports, daily, weekly, monthly, of the change managements and successes/failures.

Thanks,

Rob