MSS and SoX compliance

[hofmann]

Hi,

when I use Manager Self-Service to display and modify financial data over the Enterprise Portal in an Intranet environment, has the conection between the portal and the desktop to be encrypted (SSL/HTTPS) to be SoX compliant?

br,

Tobias

[Former Member · Accepted solution]

SOx does not require data to be encypted during transmission, but it is a type of control that should be considered.

SOx and the PCAOB do not mandate any types of controls, only that they are appropriate and can be seen (and tested) to be designed appropriately and operating effectively.

As I have said before you and your external auditor will determine whether encryption is required, if it is required at all.

[hofmann · Accepted solution]

Hi,

I tend to go with Vinay. SoX states that the integrity and confidentiality is essencial. When I do all the work in the backend (Crypt, Hashes, secure transfer, monitoring, etc), but don't care how the data gets into the backend, I open up a backdoor.

The CFO, CIO, CEO, CxO, all the people to whom SoX is pointing to when something goes wrong could say: "I didn't entered/approved this." And there is no way to proof them wrong. An expert could stand up in the court and say: everybody with the knowledge in the Intranet could've modified the data. If my auditor doesn't care about integrity and confidentiality at the stage of entering the data, maybe I should change the auditor ...

But, doesn't SoX recommend the use of a standard like COSO, COBIT, etc? Do I have to look at COBIT and the security recommendation there to know whether I should/have to implement SSL? Has someone experience with this?

br,

Tobias

[vinay_hk · Accepted solution]

1.

SOx requires the controls that are implemented in the Organization are efficient and effective. To determine this and apply is no standard approach. The processes and controls differs for every organization or rather has to be particular to each organization

2.

To decide whether you need encryption or not is a decision that has to come out of risk assessment. The real questions to be answered are:

- whether the IT process in question is critical enough to have it encrypted

- what will be the probable consequences on the company (reputation, revenue loss, competitive advtg etc) in the event of such a compromise

- what is the cost involved and whether the benefit justifies the cost

I would do a risk assessment on the process in question and then decide if it is required for my organization to have it encrypted. I see the external Auditor in the support and verifying function whereas I am the driver and the decision maker.

Finally, yes, CobiT and COSO are frameworks that are recommended by communities, they can be referred to achieve SOx compliance. SOx regulation by itself doesnu2019t mandate the use of any such frameworks though. And, CobiT does talk about encryption in PO2.3 and DS5. The mapping to ITIL is 4.2 and to ISO 17799 are 8.5/9.4/10.3

Vinay.

[Former Member]

Hi,

Any application that supports the data has to be sox compliant.

The availability,integrity and confidentiality rules will be very much applicable to your context.

But this does not automatically mean that the data has to flow only thro' the encrypted swimming lane.Encryption is recommended,but then should be justified-it is subject to cost-benefit risk anaysis.

Sox does not specify a particular type of control;all it demands is the existance of an adequate,robust control frame work and an assurance over the reliability of the" Internal control over financial Reporting".

AS5 allows us to adopt a risk based approach,meaning,if the outcome is innocous- in your context,perhaps you need not to secure it at all.Still you will be SOX compliant!!!.So how to secure and how much to secure is a question of criticality involved,the risk and the cost-benefit of a particular control.For example the intrusion of a general E-mail may not be critical;while the intrusion to a MIS Report - even in the "display" mode, will amount to a SOX violation.

Sox is about the best practices and an effective continous oversight.Whether a particular event is SOX_sensitive is subject to the above- discussed- points.

Hope this helps.

Regards.

Ramesh.

[hofmann]

Hi,

Well, to sum it up:

1. It's up to the auditor. He decides whether my control framework is accurate or not. Worst case: I choose a bad auditor and the SOx compliance won't stand up in the court.

2. What's data integrity and confidentiality is up to the data/process. As all of you are stating:

"data being entered is accurate" [Simon]

"SOx does bother about whether appropriate controls have been defined and are operating effectively" [Vinay]

"The availability,integrity and confidentiality rules will be very much applicable to your context" [Ramesh]

The usage of SSL/encryption depends on the process and on the environment. If the process/data is highly critical, I need all the mechanisms/security necessary to ensure data integrity and confidentiality. These parameters differ from external and internal access and what is already implemented in the organization (SSO, Kerberos, backend system, etc)

3. To ensure point 1+2 I can decide from varios frameworks. If the framework I selected - eg COBIT (PO2.3 & DS5) - and my implementation of this framework mandates security, I have to implement SSL.

Are there any best practices of the varios possibilities available? Like:

1. If the application is available externally, verify at least: Firewall, provide SSL, etc.

2. If the application is available only internally, verify that I&AM is compliant to ISO X, etc?

br,

Tobias

[Former Member]

Tobias,

Now that you have summarized this so nicely, I hate to confuse matters. But, it seems companies often refer to inside firewall, intranet traffic as internal. When increasingly with the advent of the portal; business partners, vendors, and suppliers all come and go via the portal to inside the network.

So, in addition to knowledgeable, disgruntled, or curious employees intercepting or altering sensitive data, external partners can do this now also. Clearly PCI standards require credit card data streams to be encrypted and information stored should be obscured from visibility even internally.

Encrypting internal data streams may not be defined by SOX, but attestations are. I tend to agree with Vinay. In my opinion, without Data Integrity and Accountability there is no control. And yes, weigh risk vs likelihood and impact. If it is not sensitive, would the expense or performance hit be worth the effort? In other words regardless of label SOX or COSO; focus on the critical data and secure it.

- Randa

[Former Member]

THE END (LOL)

[Former Member]

The auditor is concerned about whether the data being entered is accurate, up to date, entered in a timely manner etc etc.

The auditor is concerned about what controls you have in place to ensure that all of the above.

The auditor is concerned about whether the control has been operating successfully for the period of the review.

If you want to use encryption use encryption, if you don't use other controls as long as they are appropriate.

Quite frankly all of the controls in your systems could be manual if you want them to be so, it just means that you will have a harder time to prove to your auditor that they have been operating effectively.

But getting back to the original question do you have to use encryption and SSL etc etc, then the answer as it has always been is NO, you do not have to do so, it is not mandated by SOx or AS5 etc, as long as your controls framework you have in place is appropriate and operating effectively. Please note that the use of some types of encyption in some countries is illegal, therefore you can not use it even if you want to.

SOx refers to COBIT as a appropriate framework that may be followed.

[Former Member]

It is up to you whether you use encryption or not. As long as you and your auditors agree that is the only important part.

SOX is only bothered about whether appropriate controls have been defined and are operating effectively, it could not care less what the actual control is and what tehnologies are used.

[Former Member]

SOX is only interested in entries into the financial ledgers and the controls that are in place to ensure that the entries are complete, accurate and up to date.

It is up to the company in question (normally in conjunction with their external auditor) to determine whether encryption or any other other type of control is necessary.

[hofmann]

Thanks for the reply.

When I expose financial data over a portal, and the financial system/transaction is covered by SoX (normal access by SAPGui secured via SNC), do I than have to ensure integrity and confidentiality by using HTTPS?

In this case, the transcation is covered, but does SoX only apply to the transaction in the backend system or also on how I do enter/transmit the data?

br,

Tobias

[vinay_hk]

Yes, in fact it shall be a concern for SOx as well. As already pointed out, SOx does bother about whether appropriate controls have been defined and are operating effectively. But if your data transfer from the client to the backend is not secure enough and vulnerable, the control immediately becomes ineffective! So, in short, the answer to your question would be Yes, it is required to ensure that the integrity of the data transfer.

Nevertheless, SAP systems internally use various encryption protocols while updating data in the back end. So, the scenarios cited must anyways be a part of encrypted traffic!

It is absolutely necessary to realize that Intranet is as vulnerable as Internet due to threats from employees who are aware of the network infrastructure

Vinay.

Edited by: Vinay HK on Jul 28, 2008 5:24 PM

[jose-manuelvo]

I think you don´t need to have encripted conections in your intranet for SoX compliance. SoX refeer to actions that people can do in the system, not to the way you connect to the server, that is a security question.

I hope this can help, and sorry for my english

[hofmann]

Hi,

thanks for the response, but as you say: "SoX refeer to actions that people can do in the system".

Without an encrypted connection between the system and the user's desktop, how can someone be sure that

a) the data entered is also the data transmitted and inserted into the system

b) nobody is stealing the session logonticket and uses a fake ID to access and manipulate data?

In both ways, I cannot assure that the actions a user is taking in the backend are correct. I do can verify the log for an action, but if the user did make this action ... ? After all, he can deny it: "This wasn't me, someone has stolen my logon ticket/manipulated my data".

Does anyone know if SoX states, that in an intranet or general, the portal access does have to be secured, like using SSL/HTTPS?

br,

Tobias

Edited by: Tobias Hofmann on Jul 24, 2008 4:28 PM