SAP Security and the Risk to the Value Chain

There is a lot of discussion in risk management circles on how risks within the value chain can often be ignored. Paul Proctor, Vice President of Research at Gartner, recently presented a webcast titled “Digital Business and the CIO’s Relationship with Risk.” He indicates:

“If businesses start to address risks within the value chain, they will become more competitive, grow faster and add value to the business decision makers.”

Take a moment and think about how SAP supports an organization’s value chain. Organizations use SAP to track and manage, in real-time, sales, production, finance accounting and human resources in an enterprise.

Specific examples include:
Finance: General Ledger (GL), Account Payable (AP), Account Receivable (AR) and Asset Accounting.
Controlling: Includes Cost Center Accounting, Profit Center Accounting (PCA) Product Costing, Profitability Analysis and Internal Order (IO).
Sales and Distribution: Customer master data, sales, plants, sales organizations and sales conditions.
Human Resource: Resource hiring, salary, employee benefits etc. It is highly integrated with finance and controlling (FICO) modules.
Project Systems: Budgeting, planning, forecasting.


Other key systems such as email, web front end apps, and Microsoft applications also support the value chain and are of focus for many traditional perimeter and archaic security technologies. However, though these systems are important, are they as critical to the value chain as SAP?

I’ve found that many organizations assume that a combination of reactive security measures (i.e. perimeter-based, static controls and siloed management systems) is enough to “cover all their SAP Bases” (no pun intended). To ensure that risks within the value chain are properly addressed, security and SAP teams must work together and take an adaptive approach to securing their business-critical applications.

This approach includes:
◾Transforming compliance initiatives to include SAP systems in audits.
◾Deploying an effective approach for implementing efficient, automated and integrated ways to measure, monitor and review the state of compliance on SAP applications.
◾Performing risk analytics with an established risk model that identifies, assesses and tracks emerging risks to key data and processes running on SAP.
◾Ensuring the organization includes business context in the risk analytics information to ensure preparation for major events that can impact reputation.

One risk calculation for determining the impact of risks to SAP applications should include the probability of a compromise to SAP applications and expected impact of loss when compromised. In fact, on CISO of a fortune 500 company recently stated, “If our company’s SAP System is breached, it will cost us $22M per minute”. Knowing that there is that much on the line makes it imperative for an organization to have an adaptive security approach in place. To do so, organizations need to have ensured visibility into all SAP assets, the vulnerabilities that are prevalent on the systems, and any already compromised SAP assets. Additionally, it is crucial to prioritize the fixes based on business context and ultimately impact. Finally, organization must put in place proactive and behavioral based controls that continuously monitor key business-critical applications.

Leading organizations have embraced the fact that their SAP infrastructure is not secure and have already begun taking a different approach to SAP security. Being proactive, and identifying gaps in existing security plans before an attack takes place is now critical for success.

Over the course of the last month, Adrian has published an ongoing blog series titled “Building an Enterprise Application Security Program.” This is a great series with use cases and recommendations for best practices around how to build an effective security program for your SAP landscape. During the live webcast, Adrian will expand on the issues presented in his blog, and will discuss security challenges that are likely facing your organization.

For more information on SAP security recommendations visit the Onapsis Blog at:


Leading GRC Platform Used as a CIO Dashboard

During this year’s EMC World in Las Vegas the leading GRC platform was presented during a record attended keynote with Jeremy Burton and Jason Rader who shared GRC from the perspective of a CIO.

This example is one of many use cases that a GRC platform can enable executives to have a clear “real-time” picture of their risk posture.

RSA Conference Talks Big Data


I just came back from the RSA Conference in San Francisco where I couldn’t turn a corner without someone talking about how Big Data was revolutionizing the security industry. In fact, there was one session that stood out during the conference for me. It was titled “Managing Advanced Security Problems Using Advanced Security Analytics” where Eddie Schwartz, VP and CISO of RSA moderated a panel comprised of four industry analysts including Scott Crawford, Research Director of Enterprise Management Associates; John Kindervag, Senior Analyst at Forrester Research; Neil MacDonald, VP & Gartner Fellow of Gartner and; Jon Oltsik, Senior Principal Analyst from Enterprise Strategy Group.

The panel discussion covered quite a bit of ground including defining what Big Data actually means, the acceptance within security organizations of using big data analytic techniques as well as the prediction of when security professionals will embrace big data analytics and finally how big data can be the answer to the advanced threat problem with it’s incredible scalability and high speed analytics.

Discussion point that I agree with:

1)     Everyone from the moderator to the panel participants acknowledged that the current approach that companies are taking to manage the advanced threat problem fail due to lack of event context and constraints in traditional IT architecture. The panel also pointed out that there are many organizations that are not changing their ways from traditional perimeter based security, anti-virus, etc. due to “what we don’t know won’t hurt us” mentality which leaves the security teams with archaic technology that leaves them with no visibility into the threats that affect their business.

Discussion point that I did not agree with:

1)     Heat maps are a must to provide visualization. This is something I cannot agree with as the notion of a heat map is even to a risk professional becoming obsolete as they only provide a two dimensional view into the risks that could affect the business. They are not multidimensional and only provide areas of risks vs. different views into key risk issues with details.  I have seen organizations phase out heat maps and phase in multidimensional models that provide a way to view risk data from different dimensions so you get a risk portfolio vs. just pretty colors from a heat map. It also should result in creating risk intelligence so organizations can make informed decisions which can and should be enhanced by risk simulations from quantitative models. What was funny was in another meeting right after the session I was handed a “global threat” heat map of the world which showed different threat colors by country on the size of a business card…..which was of no use.

The conclusion to the session did send me away with a good feeling because what I heard was that by using Big Data it solves many things that GRC programs should do which is breakdown information silos, automate the capture of information, normalize/correlate data and organize the information to be able to respond to risks in an organized/prioritized fashion. Sound familiar? I just can’t wait to see the scale of information capture and speed of analytics better enable the “R” in GRC.

Creating consistent processes for eGRC: a negotiation about change

When you’re trying to integrate and align governance, risk management and compliance, where do you start?

With processes.

This has been one of the hottest topics that the RSA Archer eGRC Community has been discussing during the recent eGRC Roadshows that I have been extremely honored to be a part of this fall. The conclusion that organizations have all agreed on is that you need to identify the key processes across your business that relate to enterprise GRC activities, find the commonalities and intersections, and make changes as necessary to create consistency across them.

This is both easier and harder than you might think:

  • It’s easier than you might think because the majority of GRC processes across the business will mostly be very similar to one another. People will use different names for things and think that they’re doing something very different from others, but in terms of underlying principles and steps, they mostly won’t be.
  • It’s harder than you might think because people won’t want to change what they’re doing. Even if it’s just a name change, eg changing an ‘incident’ to be called an ‘issue’, people will fight hard not to change what they’re used to. Processes and their naming conventions can be really personal; they frame how people think about what they do. If you ignore this and try to be dictatorial about process change, you’ll be in for a hard time. To illustrate my point I present to you two examples of pretty much the exact same process for both ‘incident’ and ‘issues’ management. As you will note, the only thing different is what you call each stage of the process. 

Issues Management Process

Incident Management Process









Negotiate change

So when you’re setting out to break down GRC silos and create common processes, you need to allow plenty of time to negotiate process change. The role of a GRC advocate or leader is to orchestrate this negotiation, not impose change on people. If you want to be successful you need to help people to their own conclusions about why the change is necessary and not as bad as they think.

This applies even if you’re just changing the naming conventions (taxonomy) associated with processes (I’ll cover taxonomy in a bit more detail in my next blog). It applies even more so if you’re improving a bad or mediocre process, ie making actual process change. Process change is important if your processes don’t reflect best practice, otherwise the danger is that the improvements you make through eGRC will just make mediocre results happen more quickly.

So to reiterate, every eGRC project should:

1. Start with process.

2. Create consistent eGRC processes across the business.

3. Improve poor or mediocre processes.

4. Negotiation change in Taxonomy.

Business continuity as an element of GRC. Is there really any debate?

By Alex Bender, Director, eGRC Programs and Strategy, EMC

Is GRC business continuity’s future? This is a question posed recently by Continuity Central, an information portal for business continuity.

It won’t surprise you to hear that I’d give that question a resounding ‘yes’ and that I consider this market trend to be a positive thing. What is also encouraging is that  the majority of respondents over at Continuity Central agree with me.

I’m tempted to say that the answer is so obvious, there’s nothing to debate. But maybe that’s because I’m looking at it from the enterprise GRC perspective. An integrated approach is, after all, the whole rationale of enterprise GRC as a discipline. How can you claim to have an effective eGRC program if you don’t have plans to ensure the continuing operation of your business in the face of events that threaten to disrupt it?

Will integration destroy business continuity?

Maybe it’s not so clear if you look at it from the perspective of business continuity professionals. Maybe you don’t see what’s to be gained by ‘submersion’ of your discipline within a larger eGRC discipline and paradigm. For those commenters at Continuity Central who think that it would be a negative thing for business continuity to become an aspect of GRC, there seem to be two main worries:

  • Some fear that integration would make it harder to serve the specific needs of business continuity with the specialist skills it requires. One commenter expresses it in this fashion: “BCM is a specialist subset of risk management that should be highlighted, not submerged under some generalist classification.”
  • Some believe that GRC doesn’t work and would therefore be toxic to the established principles and practices of business continuity management. One commenter expressing this view says that the standard risk methods are based on flawed assumptions; and he or she asks: “Why not ‘governance, continuity and compliance’?”

Integration is not dissolution

To me these aren’t real objections. In my experience it’s just not true that integration of different disciplines has to make any of them less important or specialized. Nor would I ever recommend an approach that doesn’t preserve best practices within individual sub-disciplines of eGRC.

That’s why I think it’s important to leverage a single eGRC technological platform with the flexibility to have individual solutions built on it for the many functions of eGRC. The whole idea is to preserve the specifics of each function — such as business continuity management, policy management, incident management, compliance management, vendor management, etc — while at the same time giving you the visibility and control to do it all more efficiently and effectively with cross-functional relationships, workflows and reporting across all functions.

As for fears about the effectiveness of eGRC, clearly there are good and bad ways to approach any discipline. Those of us who’ve spent years developing the theory and practice of eGRC think we know quite a bit about how to do it well. And I’ve seen the difference that an integrated approach can make, including for business continuity management. If you keep an eye on this blog, I’m planning to bring you a case study that illustrates the benefits of applying the best practices of eGRC to business continuity management and how BCM can be tied to the broader risk function.

Why not governance, continuity and compliance?

For those who ask why not governance, continuity and compliance, to a certain extent it’s a matter of how we define our terms. The diagram below comes from an EMC paper on business continuity.* As it illustrates, we see risk management as concerning itself with more than the subset of risks dealt with by business continuity management. For example, if you’ve translated financial risks into IT, operational or legal terms, the information and activities that result from this financial risk management would extend beyond business continuity initiatives.


If you widen the meaning of the phrase ‘business continuity’ enough, so it means something like ‘successfully continuing business’, then you can see it as overlapping a lot with risk management.

But really, risk management as a discipline is much more than business continuity, especially if you use the Enterprise Risk Management – Integrated Framework from COSO(the Committee of Sponsoring Organizations of the Treadway Commission) as the foundation of your risk management program (see diagram below).

However you choose to define your terms, my point still remains that a siloed approach to any continuity/risk management discipline is not the way forward. And again, watch this space for a case study that illustrates this beautifully.


Recommended Reading:

* Getting Your Business Back: Pulling Together Business Continuity, Crisis Management and Disaster Recovery, an EMC Consulting paper

A General Lack of Compliance Cooperation – Article Post

By Alex Bender, Director, eGRC Programs and Strategy, EMC

Recently I had a discussion with Mike Vizard who is one of the leading reporters on GRC and how IT works with the multiple domains across the organization. He wrote an article titled: A General Lack of Compliance Cooperation. In the article he presents some of the recent findings in a recent survey/study of over 191 GRC practitioners from the RSA Archer eGRC Community.

My favorite finding in the article is that it is clear that risk assessments, policy management and controls assessments are widely implemented. Through my countless interactions with enterprises around the world these elements are essential in implementing a solid eGRC strategy. Top companies implement these core GRC elements to also monitor, assess and validate 3rd party organizations adherence to policies and to uncover risks. As he pointed out…monitoring 3rd party risks is one of the key issues that companies are dealing with today and the companies who are not doing it are in jeopardy.

I urge you to read the article and download the survey from The Ponemon Institute.

EMC and the Ponemon Institute will also be presenting the results of the eGRC and Privacy Management Survey during a webcast on July 12th at 10am Central US. Click here to sign up and I look forward to all of you asking Larry Ponemon questions as well as participating in our webcast polls.