SAP Security Blogs
Turnkey's team of expert consultants share their wealth of knowledge and in-depth insight into SAP security and controls in a series of blog posts.
Friday, 2 October 2015
Posted by Marc Jackson
Increasingly the market is focused on automating controls to reduce the cost of compliance, improve the control environment, and realise efficiencies. More than ever now, organisations are completely information-driven and data has become the lifeblood of any business. In the past, organisations were able to manually verify and audit the accuracy, consistency and reliability of the information they used due to low-volumes and relatively stable mainframe-based information processing environments. However, with the advent of distributed technology, data volumes and compliance requirements have increased exponentially. As a result, the use of manual controls has become costly, obsolete and simply not sustainable.
Despite organisations becoming more and more aware of the value and benefits associated with controls automation, the current situation is not what you might expect. With the exception of a few progressive organisations, controls in most organisations are compliance-driven and often implemented following a risk event. It is not uncommon for manual controls accounting for more than 70% of key controls within an organisation, and there have been many studies and surveys which all provide similar conclusions
So why is this the case?:
- Controls tend to be implemented as a knee-jerk reaction to problems
- The absence of any recent and/or glaring information-error event means control automation projects take a backseat and compete among many organisational priorities
- For some executives, especially those who are not accountants, risk and control-related terms can be confusing and misunderstood especially when the focus is on heavy theory
- Implementing further technology to automate controls can also be a seemingly expensive proposition.
We’ll take a closer look at some further challenges faced a little bit later on, but right now let’s refresh our understanding of some of those commonly used control terminologies
As I’m sure you’re all aware, controls are typically categorised in terms of their nature and type, each of which has two buckets for classification purposes. The nature of a control is determined based on whether it is preventive or detective:
- Detective controls: will identify when a potentially undesirable activity has taken place, they will not stop it from happening but they will allow an organisation to respond appropriately and in a timely manner – so they’re very much reactive or “after the event” (e.g. a monthly review of payroll audit reports help identify potentially incorrect or unauthorised payments that have been made, such as duplicate payments or unusually large amounts, so they can be corrected as required).
- Preventive controls: on the other hand, will prevent an undesirable activity taking place, which avoids the need for potentially complex and lengthy investigations and associated corrective actions– so they’re very much proactive or “before the event” (e.g. 3-way match is a well-known configurable control ensuring quantity and price matches between PO, GR & IR according to customer-defined tolerances, otherwise the associated invoices are blocked for payment).
The control type is determined based on whether it is manual or automated. The difference between these two types of controls is relatively simple, manual controls require human intervention for them to operate whereas automated controls don’t, they are performed entirely by the system/application (e.g. you can configure an automated check on customer credit limits during order intake, if the credit limit is exceeded then the order is prevented).
You may have also heard controls referred to as “semi-automated” or “IT dependent”, these are controls which rely mainly on human intervention for their operation but they are also reliant on data provided by supporting technology. Therefore, these would include any controls involving the manual review of system-generated reports, so the manual review of FF logs is a good example. It’s important that an organisation’s internal control framework has the right balance of manual, automated, preventive and detective controls. Although preventive controls are stronger as they stop undesirable events taking place, detective controls are also important to pick up on anything that slips between the gaps, which may also be symptomatic of automated control failures.
When people hear the term automated controls they usually think of those configurable controls which are available within your ERP system that can be switched on and defined to suit the way an organisation’s business processes operate. These controls are commonly referred to as “Application Controls” and are embedded within an organisation’s business processes providing input, processing and output controls. For organisation’s embarking on a journey of automation it is strongly recommended that these controls are reviewed initially as they are readily available to use in your system, you don’t need to purchase additional hardware or software, only the relevant level of knowledge regarding the available configurable controls in those business processes being operated by your organisation.
These traditional automated controls are not only restricted to business process-related configurable controls, they also incorporate security-related system parameter settings which help define and automatically operate logical access and authentication controls. In addition, although perhaps not realised by everyone, restricted access controls are also another form of automated controls as taking away inappropriate access, whether it be for SOD or Critical Access risk purposes, removes that access risk from the user and will continue to do so without the need for any human intervention.
Example: A company can make use of a system configuration-based control which can prevent field changes to financial documents after posting to the General Ledger has taken place. For example, you’d want to prevent changes to vendor bank account details to reduce the risk of inappropriate payments. From a control perspective, if a document needs to be changed for valid reasons then it should be reversed and the correct document posted, providing full transparency into all transactions affecting the SAP General Ledger. Therefore, this helps to protect the accuracy & validity of financial reporting. An alternative manual control would involve extensive and time consuming reviews of GL document changes, so you can begin to see the positive impact of implementing automated controls.
Thursday, 17 September 2015
Posted by Richard Hunt
In EU law there is an important distinction between a Directive and a Regulation – a Directive must be implemented by each member state, a Regulation becomes law in all member states upon implementation. As a consequence this new UK data protection legislation will become far more stringent than it has ever been.
The good news is that the new regulation will not be fully in force until 2017/18 so there is still time to prepare. One of the key changes is the concept of privacy by design. Similar to the idea of the least access principle, privacy by design requires that a company’s IT systems have been designed with data privacy compliance in mind. In practice this means that SAP customers will need to ensure their access controls support compliance with the regulation and that access to personal or sensitive data is justifiable and restricted to those who need it for legitimate purposes.
Whilst compliance with the new regulation will affect access controls in a number of SAP modules and there will be a number of industry specific risks, it will be SAP HCM and/or Success Factors customers who will certainly be affected. The initial draft of GDPR has proposed a series of mandatory icons which will need to be used to provide an overview of the status of an organisation’s compliance to the regulation. These icons provide a useful summary of the key requirements:
This will provide a requirement to justify the purposes for which the data is being held and processed. The requirement will have a number of implications with regards to the collection and retention of customer and supplier data and will also affect data held on employees in an HCM context.
Data retention is an area where many SAP implementations are going to need to tighten up in order to achieve GDPR compliance. For example, holding the full HCM record of an employee after he/she has left the organisation could be considered a breach given that the company will have no justifiable reason to retain details such as dependents or next of kin.
This requirement has some interesting implications for predictive analytics and other Big Data applications. Was data collected by the organisation for these purposes and can this be considered a reasonable extension of the data usage?
Whilst organisations may not intend to disseminate, sell or rent the personal data, they hold an obligation to ensure their employees do not is also implied by this requirement. Therefore, access controls and the ability to restrict data downloads will become increasingly important.
Insisting on the encryption of an entire SAP database is likely to be met with significant resistance from the BASIS team for a number of reasons, not least of which is performance. HANA databases have been built with encryption capabilities as standard but for those SAP customers without the luxury of a HANA landscape, compliance to this obligation will be a significant challenge.
Interestingly GDPR compliance will apply a test that will look familiar to those of us with an audit background:
- it must be designed so the controller is compliant if it is followed; and
- it must allow it to demonstrate such compliance to SAs and to data subjects
This is basically the test of design and operational effectiveness applied to controls during an audit. Roles and authorisations clearly play an important part in the implementation of a GDPR compliant solution but other tools will also be useful:
GRC Process Controls
Tools such as SAP GRC Process Controls will be very useful in the implementation of a GDPR compliance programme:
- Documentation of the organisation’s GDPR compliance procedures
- Assignment of control ownership and operation of these controls using PC workflows
- Documenting and issuing Data Protection policies and amendments using the Policy Management component
- Issue management and remediation
- Demonstration of GDPR related compliance activities
- GDPR compliance sign-off
Read access logging
The new Read Access Logging functionality inherent in SAP Netweaver will be extremely useful in the implementation of monitoring controls. Allowing access to sensitive data to be monitored at a more detailed level will provide an alternative where an access controls solution would be too restrictive.
Thursday, 6 August 2015
Posted by Tom Venables
So, knowing that trust is defined as “having confidence in the veracity, integrity or other virtues of someone or something”, how would you rate the trust you have in the following:
- The accuracy of your data?
- Integrity of the systems which store your data?
- Security of communication between systems?
- The integrity of the people in your organisation?
- The organisations which work to support you?
- The processes which are in place?
If any of the above gave you pause for thought, you are probably not alone! I have seen examples of all of these being called into question at some point and, like all of us, have worked to improve the trust in the people, companies, systems and processes involved.
Once trust or confidence has begun to be eroded, it can be extremely difficult to re-establish, if it can be regained at all. It is possible to handle a lack of trust, establishing proper governance and control processes, supported by tools can help us to continue to operate in environments where trust is an issue.
Trusting the people
We trust the employees in our company with the data they require to perform their job function. We do, however, still establish mechanisms to protect both the organisation and the employees themselves from the ability to realise risk. It is important that this protection is understood to work both ways – the company can have faith that “John Doe” cannot commit fraud and “John” is confident that he will be blameless in the event that fraud were to happen. Establishing the employees’ responsibilities in managing risk are key to achieving our governance and compliance goals.
Maintaining control of segregation of duties risks, whether through role design, or supplemented with GRC access controls, is one mechanism by which we can establish trust between the employer and the employee. This is even more relevant for managed service organisations, where they are being trusted as the custodians and protectors of their clients’ business-critical information and systems.
Trusting the systems
Ensuring the integrity of the systems and data your business relies upon is key. Anything which undermines confidence in those systems needs to be addressed and there are a number of procedures which can improve the reliability of, and confidence in, those systems.
Ensuring correct change controls are in place for enhancements should ensure that nothing untoward is introduced into the live systems, however this needs to be backed up by robust testing from the correct stakeholders, with particular emphasis on integration testing, as nothing will erode trust in new systems faster than negative UAT or live issues.
We often see cases where functionality tested (and working) in isolation in pre-production systems does not “play well” with live data, or other functionality. Making sure that issues with integration are addressed before go-live will increase business confidence in the IT systems and the organisation which supports them.
The bottom line is: Ensure you have the processes in place to protect the people and systems your business needs, supported by the appropriate tools and you will improve the trust, truth and confidence in those people, systems and your own organisation.
Please feel free to comment on your own trust issues, or examples of what’s worked well using the link below:
Thursday, 23 July 2015
Posted by Tom Venables
How sensitive is your data?
With data theft becoming more prevalent and a heightened media focus on loss of personal data affecting several notable companies in recent years, the protection of data has never been more relevant to systems administrators and governance functions. Whether it be protecting employees’ personal details, the financials behind shareholder statements, or critical customer information, it is essential that we understand the data stored in our systems and undertake implementation of processes and tools to protect this.
As with so much in security, the most important piece of achieving controls around data protection is human: we should ensure that all employees who are dealing with sensitive data understand their responsibilities and the requirements for the protection of said data. An understanding of data and the associated risk ownership in the business is essential for this.
Where is your data right now?
Do you use file sharing? How about pre-production copies of production data?
Ensure that you have a complete understanding of where sensitive data is stored and how it is transmitted and you will understand the scope required for implementation of controls around access to that data. If you have production data stored in non-production systems, then you need to bring those into the scope of your controls framework and may be exposed to clauses in data privacy legislation which require data to only be stored once, for specific processing purposes. Remember that production controls should be applied to production data, wherever it is stored or accessible, this may include management information systems as well.
SAP provide a number of tools to enable you to protect your data, the first of which is incumbent upon your role design, denying access to data for those users whom it is not deemed appropriate. Reporting on the setup of roles and who can access what data is fairly straightforward in standard authorisations, but can be complicated by more complex authorisation solutions, such as structural authorisations in HR.
For example, managers may have access to payroll information to enable MSS functionality through a portal solution, but may not be able to display this information in the backend SAP GUI. Make sure you understand the processes used to access data to avoid spending time and effort on these false-positives.
So, assuming your role design is already limiting access to data appropriately, you may still have concerns around other types of access. For example, confidential data may be extracted from a system and stored offline or on file-shares, how can you work to prevent this?
GRC Access Risk Analysis can help bolster your reporting in this area, permitting the linking of display access to data with the transactions required to misuse that access. A note of caution though – I would recommend any reporting rules set up for monitoring read access should be kept distinct from the rules around segregation of duties, in order to provide clarity of reporting on risks – consider a custom ruleset for specific DP risks.
Read Access Logging allows you to monitor and log read access to data you deem to be sensitive. You can define which data you want to be logged and ensure that monitoring of access can be conducted. The key advantage of RAL is that it should be available to most SAP customers, as long as your BASIS patch-level is up to speed. There is a guide in SAPNote 1969086 to check your compatibility.
UI Logging: While at first glance, this may seem similar to the RAL solution, UI logging provides some additional functionality when dealing with sensitive data, allowing you to see the exact set of data being displayed. Providing reporting cockpits for identification and trace tools of data incidents, it is configurable to determine which users and data logging should be enabled for.
UI Masking: Going further than the UI logging solution, UI masking offers more preventative controls for handling sensitive data. The solution can mask data within the GUI, ensuring that sensitive fields are not displayed. It can be configured to only display data to people with the correct roles defined in the tool, as well as providing audit trails of data requests. Using these tools in conjunction with your role design and increasing organisational awareness of privacy requirements and sensitive data handling, you can help to ensure that your data remains, yours.
If you would like to know more or would like to comment on this topic, please use the link below:
Wednesday, 6 May 2015
Posted by Marc Jackson
Process Controls as a concept
Although the name may suggest, it isn't simply about providing control solutions for your business processes, rather it describes the concept of providing an overall control and compliance management solution for your organisation. This means having a single centralised solution to coordinate and manage all of your controls and compliance related activities.
GRC Process Controls
SAP GRC Process Controls provides functionality in five broad areas which support both the lifecycle of a control and the underlying controls management processes and procedures required to comply with associated regulatory standards.
1) Document - Document controls and policies centrally; map to key regulations and impacted organisations
2) Scoping - Perform periodic risk assessments to determine scope and test strategies
3) Evaluate - Evaluate control design and effectiveness; raise and remediate issues
4) Monitor - Perform automated, exception-based monitoring of ERP systems
5) Report - Support decisions and promote accountability with insightful analytics and sign-off
Automated Controls Monitoring
Process Controls provides the ability to automate monitoring of configuration settings, master data and transactional data related to key control activities. For example, monitoring and preventing duplicate payments. Below is an example of a scenario where automated monitoring could be successfully applied with associated benefits over control assurance.
Control deficiency in an organisation
There is a system configuration-based control which prevents field changes after posting to General Ledger, providing full transparency into all transactions affecting the SAP General Ledger. Any changes to this control means that the system is potentially exposed to the risk of fraudulent transactions or mistakes being made leading to inaccurate financial reporting.
For example, a user with access to OB32 may change this setting allowing vendor bank account details to be changed after posting. The risk is that inappropriate persons may receive payments, particularly if this configuration setting is not routinely checked. The company may leverage the automated control monitoring functionality in Process Controls to markedly reduce the risk in this scenario. In order to achieve this, a Business Rule can be defined looking at the bank account field to see if ‘Field Can Be Changed’ is set to X or not (‘X’ meaning that changes are allowed after posting), and could be scheduled for hourly monitoring. A control deficiency would then be automatically detected and an alert will be sent to the control owner allowing them to respond accordingly as part of the in-built issue remediation process.
Process Controls & Access Controls Integration
With the release of GRC 10.0, Access Controls and Process Controls no longer come as isolated applications as they are offered as an integrated solution. This new unified platform enables increased harmonization of key master data, where organization, process and control structures can now be shared across components of Access Control and Process Control, and this in turn supports a more integrated approach to governance, risk, and compliance. A big advantage of having the functionality of both Access Controls and Process Controls is the ability to perform continued monitoring of your SOD & critical access risks, which might otherwise be checked on a much less frequent basis. Additionally, by using Process Controls to maintain, monitor and assess your mitigating controls you instantly have greater visibility over their operating effectiveness based on their latest test, assessment or monitoring results. You can also use Process Controls to ensure that your GRC solution remains ‘fit for purpose’ at all times, which helps to underline its integrity and ensure you can rely on the risk and controls-related information it is reporting on.
- Manage, maintain and coordinate multiple compliance initiatives from a single repository with greater efficiency and improved visibility
- Automation of controls monitoring, testing and assessments
- Improved communication and adherence to policies
- Integrating Process Controls & Access Controls solutions to enhance compliance initiatives
- Reduced effort to achieve audit compliance
Marc will be re running this webinar on 9th July 2015 at 11:00am. To sign up please click here.
- October 2015 (1)
- September 2015 (1)
- August 2015 (1)
- July 2015 (1)
- May 2015 (1)
- January 2015 (2)
- December 2014 (1)
- September 2014 (1)
- August 2014 (2)
- April 2014 (1)
- February 2014 (1)
- December 2013 (1)
- October 2013 (1)
- June 2013 (1)
- May 2013 (1)
- March 2013 (1)
- February 2013 (2)
- January 2013 (2)
- December 2012 (1)
- November 2012 (3)
- October 2012 (2)
- August 2012 (2)
- July 2012 (3)