SOX

[gany59]

Is SOX is mandatory for the hp-ux servers. what is SOX complaint and how to recover those complaince, coz i am new to this concept SOX.

Could any one pls help me out on this.

[Patrick Wallek · Accepted solution]

SOX = Sarbanes-Oxley Act

>>what is SOX complaint

Sox is a BIT "complaint" for a lot of people.

But I think you probably meant "compliant". SOX compliance is a moving target and what it is exactly will vary according to who you talk to.

Some major points of SOX compliance, at least from my perspective:

1) User separation of duties -- Users are only allowed to do what they need to do, no more.

2) Administrator separation of duties - DBAs don't have root access, application admins don't have dba access, root usage is somehow controlled

3) Change control -- System and or application changes are tested and reviewed prior to implementation on a production system.

4) Backups - Do you have them? Do you test them?

5) Disaster recovery / Business Continuity - Do you have a plan? Do you test it?

6) Developer access - Can they develop / move code into production without proper review? (see # 3)

7) System security - Are proper steps taken to secure the system from unauthorized access? Are security patches applied regularly? Are unnecessary services turned off? Do you use SSH rather than telnet/ftp/rlogin?

I am sure there is more that will come up, but to ensure you are compliant you need to speek with your manager and/or your SOX auditors.

[Patrick Wallek]

>>Sox is a BIT "complaint" for a lot of people.

Should be:

Sox is a BIG "complaint" for a lot of people.

[Doug O'Leary]

Hey;

That is a *HUGE* can of worms.

SOX is the acronym that refers to a US law typically called Sarbanes Oxley. The law was designed to make the accounting fiascos that happened in the late 1990's early 2000s impossible. I'm not sure what affect it had on that; however, it's done wonders for SA and security professionals' work load.

No, SOX is not required for HPUX systems. It's only required for US based systems (or, potentially, foreign systems that do business w/the US - I'd probably argue that one, though) that handle financial data. If you don't fall into that category, you can safely ignore SOX requirements.

There are no hard and fast rules for SOX systems. In a nutshell, SOX asks "do you have a security policy?" and, if so, do you follow it? If you have SOX systems, you will go through periodic audits to determine if you're actually following the procedures that you all have laid out.

If you don't have a security policy, then your systems will be audited on commonly accepted security practices. You'll also have a finding of not having a security policy.

If you do have a security policy and it differs radically from commonly accepted security practices, then you'll probably have some explaining to do. It is not the auditor's job, regardless of what they may believe, to tell you that your policy is incorrect. They will tell you where your policy differs from commonly accepted practices. Your reply will be something like "business requirement" and an explanation of that requirement.

This doesn't give you the exact answer you're looking for; however, that answer doesn't exist. The long and short of it, though: if you're systems are reasonably secure - follow commonly accepted security practices - then you won't have a problem with a sox audit.

Doug O'Leary

[Michael Steele_2]

"...Did you hear the one about Enron merging with Arthur Anderson Accounting?...The new company is going to be called Moron...".

During the attempted federal energy deregulation of the early 2000's bilking of the State of California, and with Enron and Arthur Anderson leading the way, closely followed by many, (* Tyco, Adelphia, Worldcom *), companies were cooking the books and lying to both the public, private and federal sectors in order to keep new cash investments coming in from new stock holders.

The SEC found books being cook through old login accounts of superusers or dbas or application admins who had left the company, thereby creating backdoors for use by illegal and unscrupulous.

Enron CEO, CIO, etc., would enflate profits and hide liabilities.

Sarbannes Oxley reacted to the SEC findings with the Sarbannes Oxley Act of 2001.

However, no where have I ever found a detailed list of computer crimes or acts of accounting fraud "How they did it" any where.

Everything seems a rehash of what has been already known for decades under the FASB (* Financial Accounting Standards Board *).

In my experience, control of old logins and authorization of new user accounts is what I have seen the most. And I don't know if procedures like network hardening or turning off unneeded O/S modules falls under Sarbannes Oxley, since these were being performed by most already.

[Michael Steele_2]

HI Again:

what is interesting to point out and note is how the SEC continued under the Bush adminstration after Enron.

For six years leading up to 2008, "...the inspector general's office has found that SEC regulators acted too passively and slowly in many of the 31 recent bank failures it is reviewing....".

Why the SEC failed to enforce the laws US for the final years under the Bush administration is cause for great speculation.

[Michael Steele_2]

So you've used the forum almost daily for the last 9 months when you joins and you should know by now that this

...assigned points to 176 out of 397 responses...

Should look like this:

....assigned points to 397 out of 397 responses...

http://forums13.itrc.hp.com/service/forums/pageList.do?userId=WW275212&listType=unassigned&forumId=1

Looks like everybody here is doing your job for you.

Maybe you shouldn't be here?