Key
Insights

Blog Archive

Unlocking Management Information - Part 2

Friday, 29 August 2014

Posted by Tom Venables

In the previous instalment, I described the need to clearly understand the purpose of a Business Intelligence (BI) platform used for management information and to manage the expectations placed on the system. It is important to remember that your BI system should be providing targeted, business-led reporting and not simply used as a data-dump tool. In this continuation of the series, I would like to talk about the options we have to secure the stored data for targeted reporting which can bring the business requirements and compliance together.

The first principle is: do not import sensitive data unless absolutely required.

It may seem obvious, but many organisations miss this key opportunity to ensure that sensitive data cannot be accessed in the BI platforms; it really can be as simple as ensuring the data is not there in the first place. As discussed last time, with a clear understanding of the report requirements it may be possible to include only a level of information which is not considered sensitive and therefore does not require the same level of control as that of the source system. 

By working closely with the extraction and transformation specialists from the BW build team, it is possible to ensure that these sensitive characteristics are then stored in a format which presents minimal risk of access to the data, such as aggregated information. Logical separation of the data, such as storing in dedicated infoproviders can further help to ensure that even users with the ability to create reports cannot access the sensitive data.  This is particularly relevant in systems where you must consider Data Privacy and commercially sensitive or confidential data.

Challenging the need to import data is one of the most straightforward ways in which we can assist users at all levels of the business in thinking about the need to include information in the BW systems. ETL (extraction and transformation) layers of the datamodel encompass not only the direct extraction of data from source systems, but also have the capability to transform data. Transformation provides an up-front mechanism to identify sensitive data that may be required and to manipulate it into formats which do not present the same degree of risk to an organisation, for example aggregation, which allows data to be displayed for a team, rather than identifiably linked to individuals.

Many organisations have used BI systems merely as a replacement for table queries from their SAP systems; importing all data and providing it in a format which is difficult to secure and which does not intelligently present the data in a manner which supports business processes. Ensuring that reports are process-driven will permit authorisation teams to work with management information functions and provide compliant, business-led reporting.

Once your data is extracted from source and transformed into a form which is delivering the needs of the reports, in a more compliant format, you can think about the next principles for securing reporting data, which I will cover in the next session.

If you have any comments or questions, please feel free to use the comment submission below

Make a comment

Security Engagement

Monday, 18 August 2014

Posted by Tom Venables

When should security get involved in a project?

The short answer to this is; as early in the project as possible!

One of the most challenging aspects of security for SAP projects is often seen when security teams are engaged late in the project lifecycle, when a project is already deep into the build phase of whatever development is taking place and the need to achieve functionality in a controlled, compliant manner is raised only after the requirements have been gathered. Often we see security as an afterthought to functionality and this presents a number of challenges for successful delivery.

These challenges  come about because there has been no opportunity for security to share in the design decisions, to understand the requirements from the point of view of an end-user, or to sit with process and risk owners to understand the control objectives of the organisation. 

Often, development teams proceed with creating new functionality, whether it be a portal application, a new transaction, program, or even a new report, they migrate it through a landscape and sometimes all the way to production before finding out that no-one can access their shiny new functionality. At this point, the security for the development is then handled as part of an incident management process, rather than being scoped as part of the project itself. This places pressure on security teams in terms of cost, time and results in a negative perception of the security function.

A lack of involvement from the security & authorisations function early in a project lifecycle means that important risk control objectives are often not incorporated in requirements and this can snowball and impact all phases of the project:

Design phase:

Without clear definition of the functional requirements of developments, the scope for security changes is not confirmed and it is extremely difficult to achieve a technical design which meets the requirements. Understanding the control objectives, risks which must be addressed and the technical architecture involved is essential. 

Without a clear set of requirements for both the business functionality and security, it can be particularly challenging to come up with a design for your roles which supports the needs of your organisation. In addition, security design is more effective when the needs of the business are understood by the security administrators. 

Build phase:

So, you have little or no functional / technical design documents on which to base your build of the authorisation components, but still a requirement to have roles in place to support the project. Without knowing what authorisations to grant, or restrict, the roles themselves may have insufficient authorisation (which will impact testing experience), or excessive authorisations, which will be highlighted by auditors. 

Testing:

Say you have managed, by virtue of a lot of effort in your build phase, to get roles built, the roles are handed over to UAT execution and at this point, the testers identify defects in the roles. Perhaps they permit access to some sensitive data or fail in the testing of some critical activity. These issues are then raised as defects in the role, rather than changes to the scope of the roles. Without a design, how do you know that the build fits that design?

Go-live:

If the testing phase of the project is signed off, despite (IN SPITE OF LINGERING) some lingering issues with the security, you now have to handle issues in the production system. Forcing changes through a business as usual process, you’ve got to deal with a negative perception of security, face time pressures on getting functionality working in production or may face the prospect of failed audits. At this point, your management now have to decide if they’re going to create a remediation project purely for the authorisations. This is one common justification for the creation of GRC projects, to identify issues and remediate.

How do you get early engagement?

It’s not an easy thing to change the way an organisation engages with the security teams, but one thing which I have seen work well lies in educating project and change managers about their responsibilities to include security in all phases of the project. An element of this can include stage gate approvals from security to exit each phase of the project. Using your existing change control processes, it should be possible to include a review step in the design phase and as part of stakeholder engagement to ensure that changes cannot progress until the security impacts have been assessed.

To summarise, if security is involved in sap projects from the outset, not only will it be more liekly to work, the organisation will also save time and resources it would have deployed later in the process to fix the problems.

If you have any comments or questions, please feel free to use the comment submission below

Make a comment

Unlocking information in BW

Sunday, 22 July 2012

Posted by Tom Venables

BW systems present some very specific challenges when authorising access to data, so for this series I want to talk about some of the key points of control to consider.

The first of these, as you will see, is about ensuring your reporting users understand the system and its uses:

BW is not your operational database!

While this may seem an obvious statement to make, it is important at all stages of designing your reporting solution to consider the purpose of the BW reports, it is very easy to lose focus on the purpose of a data warehousing and reporting system.

Many organisations have implemented SAP BW to provide reporting capabilities, but have fallen into the all-too-easy trap of using BW to provide data which is already accessible in the source system. Operational reporting such as this does not take advantage of the data warehousing capabilities of the tool while presenting unnecessary challenges to the authorisation design:

e.g. The need to secure fields within BW requires activation of multiple characteristics to attempt to replicate the authorisations in the source system, while this level of protection may not be essential to deliver the management information required and, due to the “all or nothing” rule in BW, can impact the delivery of other reports.

If you have identified that there are large volumes of ad-hoc reporting taking place from the BW system, take the time to understand the requirements of the highest volume users and explore options for providing similar reporting capabilities from source ERP systems. Solutions such as ad-hoc query or tailored reports from tables in the ERP can provide much more effective solutions for these users and ensure you can focus on delivering the strategic and tactical reporting for which you have invested in BW.

Why is this important?

Without a clear understanding of the data consumers, it is extremely difficult to design all components in a way which will support not only the reports themselves, but the authorisation for the data contained in those reports. It is common for operational reports to act simply as a “data-dump” tool for business users to see all detailed data pertaining to a specific operational requirement, be it tracing all information about an account, or seeing all data relating to employees. Management information often does not require this level of detail and inclusion of these details in reports presents the first point of challenge in designing authorisations – the need to secure details is often greater than that to secure aggregate data within the BW system.

An example:

Management teams would like to track bonus payments per team, but do not require the details of the payments to individuals to meet these KPI requirements. Knowing how a team is performing against a metric will tell management what they need to know, dealing with an individual case within that team takes us to a level of detail which is more appropriately handled at the detailed information level which is already available for individuals within the source system (with appropriate authorisations in place)

In this example, it is possible for the data warehousing architects to ensure that only the high-level or summary level information is presented in the reports to managers, to provide a view which will show how each organisation, branch and /or team is performing against the metrics defined. Because we do not need to display specific details of individual records, the need to secure the data within the report is lessened, which allows us to keep the authorisation concept simple. This drives cost savings in terms of support and greater transparency in the event of an audit, helping to demonstrate control across your SAP landscape.

By adhering to the first principle: Ensuring data is appropriate for the needs of the report, your authorisation specialists will be able to focus on areas where there is greater need to provide technical solutions and let the processes and understanding of BW take the lead in these high-level reports.

As we continue this series, we will look into other fundamental principles in achieving a secure and compliant BW landscape which will complement your wider SAP architecture. If you have any comments or questions, please feel free to use the comment submission below.

Make a comment
Visit Turnkey Insights