SAP Community - Governance, Risk, Compliance (GRC), and Cybersecurity

SAP Welcomes the Release of NSA-CISA Top 10 Cloud Security Mitigation Strategies

2024-03-26T15:27:10.416000+01:00

By Niall Brennan and Jay Thoden van Velzen, Office of the CSO, SAP Global Security & Cloud Compliance

On March 7th, the US National Security Agency (NSA) published 10 strategies for securing cloud landscapes. Each strategy was detailed in a separate Cybersecurity Information Sheet (CSI), six of which were crafted jointly with the Cybersecurity and Infrastructure Security Agency (CISA). Collectively, these 10 strategies are an important contribution to cloud security, especially since the recommendations are agnostic of cloud platform and cover Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS) cloud services.

As the digital ecosystem rapidly evolves toward greater interconnectivity and migration to hybrid and multi-cloud environments, the threat landscape has become increasingly complicated. The role of responsible central authorities in establishing and encouraging the use of cybersecurity “best practices” has never been more critical and active collaboration among all stakeholders, including government, industry, academia, and the research communities, in adopting and normalizing such practices are the best path to safer and more secure digital environments. SAP regularly collaborates with NSA and CISA though the Enduring Security Framework (ESF) and Joint Cyber Defense Collaborative (JCDC) public – private partnerships and applauds their leadership role with this announcement.

Top 10 Cloud Security Mitigation Strategies

Helpfully, eight of the strategies are mapped to MITRE ATT&CK® adversary tactics and techniques, as well as D3FEND™ cybersecurity countermeasures (we have marked those in the list below with a “*”). Many organizations, including SAP, use the ATT&CK® and D3FEND™ matrices to structure their security programs. These references are likely not included in the first and sixth strategies because there are no obvious matches for them (yet).

Uphold the cloud shared responsibility model
Use secure cloud identity and access management practices (Joint with CISA)*
Use secure cloud key management practices (Joint with CISA)*
Implement network segmentation and encryption in cloud environments (Joint with CISA)*
Secure data in the cloud (Joint with CISA)*
Defending continuous integration/continuous delivery environments (Joint with CISA)
Enforce secure automated deployment practices through infrastructure as code*
Account for complexities introduced by hybrid cloud and multi-cloud environments*
Mitigate risks from managed service providers in cloud environments (Joint with CISA)*
Manage cloud logs for effective threat hunting*

The discussion of the cloud shared responsibility model helps determine where the responsibility is to manage different tactics, techniques, and countermeasures. For Continuous Integration/Continuous Delivery (CI/CD) environments Software Deployment Tools (T1072) is likely the best fit, but it could be argued it lacks a sub-technique for precision.

These strategies are very useful recommendations and provide strong confirmation that we at SAP have been on the right path in the development of our own cloud security programs. The mitigation strategies cover several areas where SAP has already implemented controls to remediate their associated risks and will be of great use to those working through cloud security challenges now.

Shared or Separated Security Model

The collection starts with a discussion of the Shared Security Model for cloud security. SAP is a SaaS and PaaS cloud service provider, but most of those cloud services run on public cloud providers like Amazon Web Services (AWS), Azure, Google Cloud (GCP) and Alibaba Cloud. Therefore, we need to adjust this model to one that covers three different parties, rather than two.

Shared or Separated Security Model for SAP cloud solutions deployed in public cloud landscapes

The use of “shared” can be misleading. The three parties in this diagram have separate and distinct responsibilities for different parts of the solution stack. SAP needs to secure the IaaS and PaaS services used in the landscape, as well as the system configuration, secure provisioning, and cloud operations of the SAP solutions. That covers the primary scope of the mitigating strategies published by the NSA and CISA. In addition, SAP covers multiple security functions across the layers of the stack, as well as SAP’s corporate network, IT, and data centers, as well as the physical safety of our employees and facilities.

SAP’s Approach for Mitigating Strategies

In the sections below, we cover how SAP manages several main recommendations from the NSA/CISA remediation strategies. In past Security and Compliance blogs, we have covered the cloud guardrails that protect SAP and its customers against common cloud threats by making cloud accounts, subscriptions and projects more secure-by-default. Considering the size and scope of the landscape they apply to, they are perhaps our most effective security controls. Most of the examples below are enforced by these guardrails.

Cloud Identity and Access Management (IAM)

Enforced by the cloud guardrails, all cloud administrators must have SAP-provisioned identities. It is, therefore, not possible for adversaries to create their own accounts under other domain names. Cloud administrators must authenticate with their SAP identities using MFA on an SAP-enrolled device. In addition, SAP has a variety of phishing detection and defensive measures in place.

Cloud Logs

Cloud audit logs are centrally collected from all cloud accounts for ingestion into the central SIEM platform, where these logs are processed and enriched with asset inventory and organizational metadata. That makes them available for threat detection and hunting, alongside other security scanning data sources.

Key Management

Cloud guardrails enforce the secure configuration of cloud provider Key Management Services (KMS). SAP offers customers several key management options, through software or hardware key storage, as well as SAP Data Custodian, which allows customers to manage keys themselves.

Encryption and Network Segmentation

Transport Layer Security (TLS) 1.2+ with the weak cyphers removed is enforced on network connections for cloud infrastructure. That includes access to storage. Encryption-at-rest is enforced on disk volumes and storage buckets, where that is not already the default provided by the public cloud service provider.

Many of SAP’s cloud solutions are deployed “single tenant”. That means that customers have their own instance of the cloud solution. For SAP S/4HANA Cloud Private Edition that includes tenant isolation by cloud account, which means there is no network path to other landscapes other than the customer’s corporate network. In other single tenant solutions, separate instances are segmented into isolated Virtual Private Clouds (VPCs). SAP blocks several common administration ports from the internet, including Secure Shell (SSH) and Remote Desktop Protocol (RDP).

Infrastructure as Code and CI/CD

The scale at which SAP operates means that we have long since moved to automated deployments through Infrastructure as Code (IaC) and CI/CD pipelines for SAP cloud solutions. This ensures that deployments are the same across instances, that the same release is deployed as has gone through development and pre-production testing and can be restored or rolled back more easily in case of incidents. IaC is checked into source code repositories just like any other code and managed through the secure Software Development and Operations Lifecycle (SDOL).

Mitigate Risks From Managed Service Providers (MSPs)

A particularly interesting and welcome strategy in the list is the ninth on mitigating risks from managed service providers. This recommends exercising due diligence, considering the provider’s security posture, and establishing audit mechanisms when choosing service providers. The concept of shared responsibility for risk must be fully understood in the MSP/customer relationship. A clear delineation and acceptance of responsibility for individual risk elements between the MSP and its customer should be an essential foundation of the relationship. The trust and transparency engendered through audit mechanisms, such as SOC 2, further contributes to a secure environment. SAP does this with its service providers, and we expect to be held to the same standards by our customers. SAP customers and prospects considering SAP cloud solutions as well as alternatives should use this strategy as a guide in their evaluations.

More Information

The following resources provide more information on SAP’s cloud security practices, including the cloud guardrails mentioned in the article. Given how many of the NSA/CISA mitigation strategies they can help with, we strongly recommend organizations to explore implementing similar controls. Visit the SAP Trust Center for broader information on security, compliance, privacy, and cloud service performance.

BCP: Business Continuity Planning for SAP S/4HANA - made easy with Enterprise Blockchain 🚀

2024-03-26T20:33:44.142000+01:00

The Threat - Why do we have to care for Business Continuity Planning ?

In most large Enterprise IT we have the High Availability, we have the Disaster Recovery, so why do we have to care for Business Continuity Planning ? Business Continuity Planning is that one layer higher than HA and DR, Business Continuity Planning comes in to play when HA and DR don't solve the problem.

Cincinnati Insurance Companies have a made a very useful Business Continuity Threat Matrix to help Enterprises identify the threats across all dimensions of their business:

This is the thing with Business Continuity Planning and the threats and the risk and the why to do it, a Business Continuity situation can come individually from different angles, or alternatively it could be the contagion of a number of unrelated events which when combined together lead to the Business Continuity situation.

Gartner in their Glossary describe it as:

For me, coming from the SAP Enterprise Technical Architecture side of the house,

Business Continuity Planning is about The Data

At the heart of the Business Continuity Plan there needs to be Business Data

No Data - No Business !

Every Enterprise has a Business Continuity Plan, and SAP has got a whole library of helpful document on it over here to help with designing the Business Continuity Plan:

The Solution for Protecting Business Critical Data for the Business Continuity Plan

This blog is going to walk through and show, how very easily, and cost effectively and robustly and simply a basic Enterprise Blockchain can provide the "sleep well at night" technical foundation of a Business Continuity Plan solution.

This is one of my favourite easy peasy Enterprise Blockchain use cases, it is sooo easy to implement for SAP S/4HANA Customers using their SAP technologies, including the SAP BTP, and so simple, and so effective, and it really shows from the perspective of the Business Requirements and the Enterprise Blockchain capabilities how natively out of the box Enterprise Blockchain Databases are so secure and so resilient.

In this blog we will focus on the heart of the holistic Business Continuity Plan, and that is the Data, Master and Transaction.

A sound Business Continuity Plan will include a solution to enable OCD Operationally Critical Data to be available to Key Users in the event of a Business Continuity Scenario.

What is Operational Critical Data? OCD is critical data required to execute to Key Business Processes as defined in BCP playbook. A Business Continuity Scenario would mean that the Company is without access to the S/4HANA for period of up to 4 weeks (or more), along with which there must be a guarantee of business continuity on the most critical operations and availability of the (OCD).

All Enterprises need to be prepared for a Business Continuity Scenario, where the Company will be running in Emergency Mode, kind of like when a car goes in to Emergency Mode, the car drives, but the car does not perform to the full possibility. We are happy the car is running and we are happy that we can still use the car.

And this would be the same for Company in a Business Continuity Scenario, not everything in the Enterprise IT will be available, the S/4HANA, the Digital Core, in the worst case could be down for up to 4 weeks, but, what needs to be available is the most basic foundational Business Master and Transactional Data. And that most basic foundational Business Master Data is the Business Partner Master Data, the Customers and Suppliers, the most basic Data which any Company depends on to operate, large or small, you need to know who your Customers are and who your Suppliers are.

Requirements for a Business Continuity Planning solution would look something like this:

Blockchain SAP Business Continuity Planning Requirements atkrypto.io

With the Business Requirements in hand, the next step in the SAP Enterprise Architect Demand Process would be to make an Architecture Review of the Demand from the Business Lead.

The first step of the Architecture Review takes the Business Lead's non-Functional requirements, and matches them to the Enabling Technology Capabilities:

Blockchain SAP Business Continuity Planning Requirements Technology Capabilities Analysis atkrypto.io

Now that we have the key Enabling Technology Capabilities we can look in our SAP Enterprise Technology Standards and see which of our Technology Standards would be the most appropriate to enable the non-Functional Requirements.

The required Enabling Technology Capabilities are as follows:

SAP Blockchain Required Enabling Technology Capabilities atkrypto.io

Looking through our Technology Standards, when we "Let the Use Case find the Blockchain" we find 1 Technology Standard which meets the non-Functional Enabling Technology requirements, and that is, The Enterprise Blockchain Platform.

The Enterprise Blockchain Platform and the Enterprise Blockchain Database have all of these non-Functional requirements Enabling Technology Capabilities natively built in and out of the box.

We can consider potential alternatives, but, what is so special about Blockchain Databases and Enterprise Blockchain Platforms, and this was discussed in the previous blogs, is that, out of the box, natively, traditional Database Products do not have the characteristics that the Blockchain Databases have:

atkrypto.io what is a blockchain

For our Business Continuity Business Demand, the requirements are solved out of the box natively by the Enterprise Blockchain Platform.

Immutable, tick that box, the Blockchain Database has immutability built in.

Resilience and availability, tick that box, the Blockchain Database Platform is distributed and decentralised, again we have this requirement baked in to the capabilities of the platform.

As discussed in the previous blog, [ SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard

] when we look in to our Enterprise Architecture Technology Standards we see there is only 1 Technology Standard in the Enterprise which is positioned with the capabilities to fulfill all of those requirements out of the box, and that is the, Enterprise Blockchain Platform and Enterprise Blockchain Databases.

Comparison Enterprise Blockchain Database and Traditional Legacy Database - atkrypto.io

Back to the Business Requirements for the Business Continuity Planning solution:

Availability of data across three Continents, we can tick that box, we can install the Enterprise Blockchain Platform on SAP Business Technology Platform BTP Kyma Runtime Service on three separate SAP BTP Instances running in three different continents. We could install the SAP BTP on a Cloud Provider in the USA, we could install SAP BTP on a Cloud Provider in Europe, and we could install the SAP BTP on a Cloud Provider in Asia. And what's more, in each Continent we could use a different Cloud Provider, so we could for example have SAP BTP on AWS in the USA, SAP BTP on Azure in Europe, and SAP BTP on Google Cloud in Asia, this way we would take the resilience and diversification of Cloud Providers to an even higher level, and that's one of the beautiful flexibilities of the SAP BTP.

Let's just pause on that one, one of the most beautiful things about the SAP BTP is, it is so easy to set up, to spin up the SAP BTP, and when you are spinning up the SAP BTP, you get a list of Cloud Providers that you can set it up on, Google Cloud, Azure, AWS and others, and you just click the one you want and press go.

This is something very special, amazing, because, you are able to spin up your SAP BTP on pretty much any of the largest Cloud Providers, and...... without having to onboard that Cloud Provider as a Vendor ! Because SAP have done that bit for you, SAP have taken care of onboarding the Cloud Providers as a Vendor and you just select the one you want.

Anybody who has gone through, or has to go through, the process in the Large Enterprise of onboarding a new Vendor will know first hand how painful that is, and how elegant and nice it is that SAP have done that for you with the BTP.

That's one dimension, but in this Business Continuity Scenario it goes further than that. We have said we will spin up the SAP BTP in three Regions, three Continents, and by spinning up the SAP BTP on a different Cloud Provider in each Continent, each Region, and then running the Blockchain on the BTP across those Cloud Providers we build in even more resilience because we make our solution Multi-Cloud !

Regarding the Security requirement, the Data Store should be secured to the highest level possible, we can tick that box as well, Blockchain Databases out of the box are not only immutable, but also have the Hash Mechanism and the Consensus Mechanism, which no other Database Products on the planet have natively. The Consensus Mechanism and the Hash Mechanism of Blockchain Databases raises the bar of built in security hardening to a level never seen before natively in Enterprise Database Products.

And finally, the S/4HANA Data will be sent to the Enterprise Blockchain Platform which is running on SAP Business Technology Platform kyma Runtime Service because of the four dimensions which were discussed in the previous blog, why place the Enterprise Blockchain Platform in the SAP BTP ?

It's very very simple....

Proximity to the Data (of the Digital Core)

Ethnicity of the Data (in the Digital Core)

Proximity to the Process(es) (in the Digital Core)

Proximity to the Technology (of the Digital Core)

So, we're following our Company's Demand Process, we've taken the Business Demand, and the Requirements, we have processed them according to our Company's Enterprise Architecture Demand Process and we have identified by matching requirements to Enabling Technology capabilities that the Technology Standard which we have in the house to fulfill these Requirements is the Enterprise Blockchain Database Platform.

The next step is to design the Solution Architecture, the Technical Solution Architecture and show the options for fulfilling this requirement.

The basics of the Technical Solution Architecture are:

. SAP S/4HANA contains Business Partner Master Data

. Every time Business Partner Master Data changes we need to send it to the Enterprise Blockchain Database Platform

. The Enterprise Blockchain Platform Tenant will run on the SAP Business Technology Platform Kyma Runtime Service

. The Enterprise Blockchain Platform Tenants will be deployed in three SAP BTP locations around the world

. The Enterprise Blockchain Platform Tenants will be deployed in each location on the SAP BTP on a different Cloud Hyperscaler

In terms of SAP Enterprise Technical Architecture it is pretty clear what the Solution Options are, and we will draw all of the Solutions Options here in the blog, but one variable, one open question which we haven't solved yet, is how to get the Business Partner Master Data out of S/4HANA and to the Enterprise Blockchain Platform.

To solve this, to get the Data from the S/4HANA there are a number of options, and in this blog we will focus on:

. Events - Event Driven Blockchain [this will need the SAP Advanced Event Mesh]

. API's - API Driven [this will need CI to call the Business Partner API on S/4 and then call the API on the Blockchain]

we will now elaborate the Technical Solution Architecture of both alternatives, Event Driven Blockchain, and, API Driven Blockchain.

Business Continuity Planning Technical Solution Architecture SAP S/4HANA, Events, Enterprise Blockchain Platform

in this option, the SAP S/4HANA is connected to the SAP Advanced Event Mesh running on the SAP BTP. SAP S/4HANA publishes a Business Partner Event including the Data, the Payload of the Event to the SAP Advanced Event Mesh on the SAP BTP. The SAP Advanced Event Mesh on the SAP BTP has Topics and Queues created and puts the Business Partner Event and Data into one of the Queues. The Enterprise Blockchain Platform which is running on the SAP BTP Kyma Runtime Service is connected to the SAP Advanced Event Mesh Queue as a Subscriber and listens for new Business Partner Data arriving. As soon as the new Business Partner Data arrives in the Queue the Enterprise Blockchain Platform places that Data as a new Block in the Enterprise Blockchain Database.

S/4HANA on SAP RISE PCE on Azure in Europe -> SAP BTP Advanced Event Mesh Azure (Europe) ->

-> SAP BTP Advanced Event Mesh on SAP BTP on AWS Europe

-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on AWS Europe

-> SAP BTP Advanced Event Mesh on SAP BTP on Azure USA

-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on Azure USA

-> SAP BTP Advanced Event Mesh on SAP BTP on Google Cloud Platform Asia

-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on Google Cloud Platform Asia

SAP Event Driven Blockchain Advanced Event Mesh Multi Cloud Business Continuity Planning atkrypto.io

The picture clearly shows the distributed Regional/Continental resilience of the solution, and the Multi-Cloud resilience of the solution.

Business Continuity Planning Technical Solution Architecture SAP S/4HANA, API's, Enterprise Blockchain Platform

in this option, the SAP S/4HANA is connected to the SAP BTP Cloud Integration running on the SAP BTP. A Periodic Job running on SAP Cloud Integration calls the Business Partner API on SAP S/4HANA and gets the latest Business Partner Data Changes. SAP BTP Cloud Integration then calls an API on the Enterprise Blockchain Platform which is running on the SAP BTP Kyma Runtime Service and puts the new Business Partner Data on to the Enterprise Blockchain.

SAP BTP Cloud Integration (Europe) calls an API on -> S/4HANA on SAP RISE PCE on Azure in Europe

SAP BTP Cloud Integration then calls an API on the Enterprise Blockchain Platform

-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on AWS Europe

-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on Azure USA

-> Enterprise Blockchain Platform on SAP BTP Kyma Runtine on Google Cloud Platform Asia

SAP API Driven Blockchain Integration Suite Cloud Integration Multi Cloud Business Continuity Planning atkrypto.io

The picture clearly shows the distributed Regional/Continental resilience of the solution, and the Multi-Cloud resilience of the solution.

Wrapping up, the goal of this blog, was to remind us all, that if we happen to have fallen in to the bad habit of trying to find a Use Case for the Blockchain, not to worry, but at the same time, forget doing that, and get back to doing Enterprise IT Architecture the way we always have done and with proven Demand Evaluation Processes which will always lead the Business Demand to the most appropriate Enabling Technology Standard, and therefore, let the Use Case find the Blockchain instead of the Blockchain finding the Use Case.

There are many many Use Cases where Blockchain is the obvious choice for the Enabling Technology Standard.

In my opinion, Business Continuity Planning, is one of the many, a "no brainer" Use Case, for the Enterprise Blockchain Platform.

Business Continuity Planning is one of my favourite Use Cases for Enterprise Blockchain, it is so simple, so elegant, and everything is done for you. Less than 10 years ago, to achieve the same resilience and security as an Enterprise Blockchain Platform would have required a shopping list of software and procedures, some automated, some human. And this is the beauty of the Blockchain Technology.

This S/4HANA and SAP BTP and Enterprise Blockchain use case is for me, the boiling an egg equivalent of Enterprise Blockchain Database implementations, it is so simple, so elegant, so easy to set up, and so brings out why the Enterprise Blockchain Platform is so special.

Wrapping Up

To wrap up, a simple reminder,

The Digital Transformation of Information Security is Enterprise Blockchain

Enterprise Blockchain is the Next Generation Data Integrity, Originality, Confidentiality Protection

Enterprise Blockchain, Enterprise Distributed Ledger Technology is re-imagining information security

If you want the easiest, simplest, most resilient foundation to an Enterprise Business Continuity Planning Solution, just send your S/4HANA Operational Critical Master and Transaction Data to The Enterprise Blockchain. voila.

And ultimately, this is all Why I love SAP and Blockchain Databases and why you should too 🚀.

In the next blogs, week by week I will be blogging Use Cases, the blogs will follow a template where the Business Demand, the Use Case is discussed, the Architecture Demand Process will be followed and the outcome will show, week by week, Use Case by Use Case, why Blockchain is the best Enabling Technology Standard for that Use Case and Demand. The blogs will also describe all of the Solution Architecture Options.

If you have a Use Case you would like illustrated, let me know in the comments and I will blog the Solution Architecture.

The good news is, as we discussed in the previous blog, this is no longer hype, we can do all of this today, and now, within the SAP Partner Edge Open EcoSystem there are enabling technology Blockchain Products designed and built by SAP Experts specifically for the needs of SAP Customers to make doing Blockchain and SAP easy, and so you can do SAP and Blockchain, today it's real and there's nothing stopping you.

So what are we waiting for ? Oh yeah, more use cases, ok, that will continue in the next blog This blog is the sixth in the series, the previous blogs are here, here, here here and here.

What do you think, are the words Blockchain, Web3, Distributed Ledger Technology, starting to appear in your Company's visions and technology visions ? What use cases are you looking at ? Let's chat about it in the comments.

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy Silvey is a 25 years SAP Technology veteran [15 years SAP Basis and 10 years SAP Tech Arch including Tech, Integration, Security, Data from 3.1H to S/4HANA PCE on RISE and the BTP and everything in between, and former SCN Moderator and Mentor alumni].

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

The atkrypto Enterprise Blockchain Platform for SAP has been designed by SAP Independent Experts for the needs of SAP Customers and to be deployed on the SAP BTP Kyma Runtime Service and leverage native integration to SAP Products.

atkrypto Enterprise Blockchain Platform for SAP has a number of unique qualities, including being the only Blockchain software in the world which has a DataCenter version and a light mobile version which can run on Edge/IoT/Mobile devices and enables data to be written to the Blockchain at the Edge where that same Blockchain is running on a Server in the DataCenter, protecting the integrity and originality of data from the Edge to Insights. Taking Blockchain to the Data at the Edge instead of taking the Data to the Blockchain.

All of this makes atkrypto,io the DePIN Decentralised Physical Infrastructure Network solution for Enterprise.

Safeguarding Data Privacy in KSA - Leveraging SAP to navigate NDMO’s Regulations in Digital Era

2024-03-28T12:05:30.971000+01:00

Blog v1.0 | Published On: 28 March 2024

Authors: @asadkhan02 , @AyeshaSafeer , @Zainab_ASalam

_________________________________________

In today's digital era, data privacy is a crucial issue for both individuals and organizations. The Saudi National Data Management Office (NDMO), in partnership with the Saudi Data and Artificial Intelligence Authority (SDAIA), has introduced stringent Data Governance and Personal Data Protection Standards. These regulations mandate all organizations operating across various industries in the Kingdom of Saudi Arabia comply by September 2024.

Failure to comply with these regulations can result in hefty financial fines reaching SAR 3 million or higher in some cases, reputational damage, legal consequences, and loss of trust among customers and partners.

To ensure compliance with these new regulations, organizations are encouraged to implement processes aligned with the 15 domains outlined by the NDMO for Data Governance and Personal Data Protection Standards. Leveraging technology as an enabler, organizations can implement robust data privacy measures and effectively meet these requirements.

Top 5 Areas part of 15 Domains outlined by NDMO for Data Governance and Personal Data Protection Standards

SAP, a global leader in enterprise software, provides advanced technologies with artificial intelligence (AI) capabilities that provide a solid foundation for organizations to implement data governance and personal data protection processes. SAP solutions enable Saudi organizations to efficiently navigate and fulfill regulatory requirements:

By implementing SAP solutions, Saudi organizations can empower their data privacy practices, mitigate compliance risks, and build trust among stakeholders. SAP technologies uphold data integrity, safeguard personal information, offer the framework for regulatory compliance implementation, and adapt to the demands of the digital age.

As a team at SAP, we are committed to supporting organizations in achieving their regulatory compliance initiatives. We invite you to take the next step by exploring how our technologies and solutions can assist you on this journey.

Contact us today to learn more about how SAP can help you navigate the complex landscape of data privacy regulations in Saudi Arabia and ensure compliance.

How to upgrade plugin systems if Decentralized Firefighter is used

2024-03-28T14:16:40.756000+01:00

Decentralized Firefighter is a good option to allow your Firefighters to logon when the main GRC system is under maintenance and not available or to reduce the high availability of the main GRC system. On the other hand using the Decentralized Firefighter moves GRC functionality to your plugin system which need to be work together with the main GRC system. This usually means that if you upgrade your main GRC system you need to do an upgrade on the same functionality in the backend system as well. Sometimes it is an easier task (just implement some Notes), sometimes - especially if session handling related enhancements are made - it is not an easy task. Upgrading to SP 21 or above from a lower SP level is belong to the latter.

The introduction of the Logoff button and the changes under the hood is require that - if you use Decentralized Firefighter - you move these changes on your backend as well. This is not necessary a hard task, especially if you upgrade your plugin components at the same time with your main GRC system. On the other hand if you have many backend systems or your upgrade plan is differ in your plugin systems, you can easily find that the upgrade is became a nightmare and these functionality will not works as expected. With this post we would like to introduce a solution and a possible upgrade plan which was became available with the recently released enhancement with Note 3435355 (Centralized) and 3435356 (Decentralized).

In normal circumstances we suggest to have an equivalent SP level of your main GRC system (GRCFND_A) and your plugin systems (GRCPINW). This is described in Note 1352498. The equivalency not necessary means that you need to have the same SP, it can be also achieved by implementing the same Notes. What you need to ensure that the functionality between your main GRC system and your plugin works and communicate the same way. What means "A" in the main GRC system should be "A" in the plugin system as well.

Note 3435356 can give you the option to handle the new functionalities released recently and provide an old behavior of the Firefighter Logon Pad. By implementing Note 3435356 to your existing plugin system (with all the prerequisite Notes), and then set SPRO parameter 4031 and 4032 to YES you will be able to use an upgraded version of the Decentralized Firefighter to be fully compatible with any Centralized scenario which is older than SP 21. With this compatibility mode you will be able to upgrade your plugin systems to the latest code level, and if all of your plugin is already upgraded you can also upgrade your main GRC system as the last step. With this you will be able to use Decentralized Firefighter at any time without you would need to upgrade your plugins at once in the same time.

To summarize what we suggest as a working upgrade plan.
1.) first you need to upgrade your plugin system (GRCPINW) for any newer SP level (preferably the latest one, but will works above SP 21 for V1200 or SP27/28 for V1100_700/731).
2.) Then implement Note 3435356 with all the prerequisites into this plugin system.
3.) After the Note is implemented set the Plugin side SPRO parameters 4031 and 4032 to YES. (Now you can use this plugin with your old main GRC system)
4.) Repeat Step 1-3 in all of your plugin system based on their annual Upgrade process
5.) After all of your plugin system is upgraded (where you use Decentralized Firefighter), you can upgrade your main GRC system (GRCFND_A) as well to any equivalent SP level above SP 21.

With these steps the hard part of moving to above SP 21 can be achieved with planning it a little bit easier.

Navigating Compliance and BPM: Challenges & Solutions

2024-03-28T17:43:40.210000+01:00

Photo by Mark Duffel on Unsplash

The regulatory terrain is in constant flux. From the EU’s GDPR to China’s PIPL for data privacy, or even industry-specific safety, employment, testing, and environmental regulations (just to name a few), the constant evolution makes it difficult for organizations to stay current and ensure their business processes comply with all relevant regulations. While it is true that these complexities can seem daunting, understanding the challenges and potential solutions can make compliance a natural part of your Business Process Management (BPM) strategy.

Business Process Management involves the systematic management of an organization’s processes to achieve specific goals, such as efficiency, effectiveness, and agility. However, amidst this quest for optimization, organizations must navigate a labyrinth of regulatory requirements. Whether it’s data privacy laws like GDPR, industry-specific regulations such as HIPAA in healthcare, OSHA for safety, or financial regulations like Sarbanes-Oxley (SOX), non-compliance can lead to hefty fines, damaged reputations, and even legal consequences.

In this blog post, I’ll delve into the complexities of regulatory compliance in BPM and provide guidance on how organizations can ensure their processes align with regulations effectively.

Challenges in Compliance and BPM Integration

First, no one said this would be easy. Anyone who tells you otherwise has something to sell. You need to understand that there will certainly be some things we will need to address in order to effectively integrate or use BPM to help manage compliance. Let’s consider a few of these hurdles:

1. Complex Regulatory Landscape: The regulatory environment is constantly evolving, with new laws and amendments introduced regularly. This dynamic nature makes it challenging for organizations to keep track of compliance requirements and incorporate them into their BPM strategies.

2. Cross-Functional Dependencies: Business processes often span multiple departments and systems. Ensuring compliance across these interconnected processes requires collaboration and coordination among various stakeholders, which can be a logistical challenge.

3. Legacy Systems and Siloed Data: Many organizations still rely on legacy systems that may not be designed with compliance in mind. Additionally, data silos make it difficult to maintain visibility and control over information flow, increasing the risk of compliance violations.

4. Balancing Compliance and Efficiency: Striking the right balance between compliance and efficiency is crucial. Overly rigid processes designed solely for compliance may hinder agility and innovation, while overly flexible processes could compromise compliance.

Solutions for Effective Compliance in BPM

With those issues in mind, there are ways that BPM (done correctly), can assist and is even designed to support. You will notice that I used the words “assist” and “support”. That is because it is important for everyone to understand that these solutions are not necessarily “out of the box” functionality that one can simply turn on. They do in fact require internal frameworks and methods of working be designed and implemented. This will require effective communication and change management from all levels. We can talk more about that at another time. For now, here are a few methods to consider:

1. Continuous Monitoring and Auditing: Implement robust monitoring and auditing mechanisms to track process performance and ensure compliance in real-time. Automated workflows and alerts can help detect deviations from regulatory requirements promptly.

2. Standardization and Documentation: Standardize processes and document workflows to ensure clarity and transparency. This not only facilitates compliance but also streamlines process management and training efforts.

3. Adaptive Process Design: Adopt an adaptive approach to process design that allows for flexibility while maintaining compliance. Leverage BPM tools with dynamic capabilities to adjust processes in response to regulatory changes swiftly.

4. Integration with Compliance Management Systems: Where possible, integrate BPM systems with dedicated compliance management platforms to help centralize compliance efforts. This enables communication between compliance teams and process stakeholders, supporting alignment with regulatory requirements.

5. Employee Training and Awareness: Invest in comprehensive training programs to educate employees about compliance obligations and the importance of adhering to prescribed processes. Foster a culture of compliance throughout the organization to reinforce accountability and responsibility.

As we have discussed, achieving compliance requires a strategic and holistic approach that encompasses people, processes, and technology. The dynamic landscape of regulatory compliance can and does present a challenge to BPM. However, by addressing the challenges and implementing recommended solutions, organizations can ensure a smoother path to regulatory compliance and thereby safeguard their credibility and maintain a competitive edge in the market.

— — — — — — — — — — — -

If you found this article helpful, be sure to click like. And course follow me for more on the topics of AI, BPM, Process Mining, Customer Experience, Digital Transformation, and Automation.

Until next time — Keep Transforming 💡

FireFighter ID login issue - FFID Status is in Red

2024-04-03T10:45:24.579000+02:00

There will be some scenarios where you need to approve the firefighter requests from NWBC or you need to extend the firefighter ID assignment validity from NWBC (with needed approvals).

However, there are some instances where the firefighters will see the below error message when they try login to Firefighter launchpad or the FFID status always shows in RED.

You have done the pre-checks like

1) No other firefighter is using the FFID

2) You are using the Centralized or Decentralized, any one at that point

3) All configs and authorizations are in place

4) You have already checked no previous sessions are running

5) You have already checked no jobs running with FFID and not available in SM04.

But still the user showing as occupied with Red color light in the firefighter launchpad.

The reason for this is, when you perform the extension or assignments of FFID in NWBC, you need to come out of that FFID assignment maintenance screen. Till then, the FFID shows its already checked-out.

Once you come out of that maintaince window, you will see the green status in the FFID launchpad and firefighters can login from there.

Thank you.

Get peace of mind for evolving compliance requirements with SAP advanced compliance automation

2024-04-08T07:00:00.023000+02:00

Tax authorities have typically been relying on period-end declarations and cumbersome audits, leaving a chance for after the fact validations and corrections. Now the era of 'post fact' adjustments is vanishing: more and more tax authorities require all data in real-time, even before invoices are issued to customers, making compliance a must-have within your business processes in your cloud ERP.

Did you know:

“By 2026, half of revenues will come from products, services, or businesses that haven’t yet been created” (1)
“65% of consumer business leaders believe their corporate tax liability will increase as result of the Pillar One/Pillar Two project” (2)
New “Spanish Plastic Tax” is expected to generate approximately €724m annually (3)
7 out of the 10 largest economies in the world either have introduced or plan to introduce mandatory electronic invoices for all business transactions (4)

To address your compliance needs, the GROW with SAP advanced compliance automation package, is a new commercial offering designed to help you transform, standardize and harmonize processes globally to comply locally, faster, and more efficiently. It also helps you respond to existing and upcoming e-invoicing regulations without compromising the efficiency of order to cash processes and ensure you have the adequate internal controls needed to safeguard your financial data, policies, and processes, as well as minimize the risk of noncompliance.

This first element of the package is the SAP Document and Reporting Compliance solution that helps you fulfill local compliance mandates - from electronic business documents to statutory reporting - and automate compliance processes.

The second element of the package is the SAP Risk and Assurance Management. It helps you centrally document and manage manual and automated internal controls over financial reporting, thus improving performance, protecting core data and processes.

Explosion of Local Compliance Obligations

You never go a full month without new tax news, as the digitalization journey of governments continues, resulting in more and more authorities pushing new e-invoicing regulations that are quickly becoming the new norm. And this is further going to increase with the “program announced by the European Union or tax initiatives in Japan, Saudi Arabia, Romania, Poland, Malaysia, Israel just to name a few.

This shift is motivated by various reasons, such as:

- Preventing tax evasion

- Increasing digitalization and controls in the public sector

- Or simply digitalizing the economy, for instance to reduce the carbon footprint

Whatever the deciding criterion behind it, the trend is clear: all tax authorities are investing in technology and introducing more demanding digital mandates:

Indicative examples of some external obligation… by no means exhaustive list!

Turning Taxes into Opportunities

With these challenges also come opportunities. The enables seamless compliance and helps companies respond to existing and upcoming regulations efficiently, in addition to improving and protecting business processes by minimize the risk of noncompliance.

It does so by providing a future-proof compliance platform with legal changes as a service, to standardize processes while complying with local legislations. Since no company is immune to anomalies, it provides the means to reduce operational delays, detect compliance issues, accelerate remediation in time for digital reporting and address issues at the source directly.

This helps achieve the following benefits:

Comply with ever-evolving Digital Mandates

Lower the cost of compliance with automation

Minimize risk of non-compliance

o One solution to fulfill all types of digital mandates from real time electronic documents to statutory reports

o Continuously address increasingly complex mandates

o Improve tax data quality and minimize the risk of noncompliance

o Remove manual workarounds and inefficient tasks

o Gain efficiency with standardized operations across countries.

o Simplify implementation of new mandates and ongoing support

o Improve financial performance and accuracy

o Increase tax transparency and auditability

o Detect compliance issues and accelerate remediation in time for digital reporting

o Address issue at the source

With SAP’s new GROW with SAP advanced compliance automation package, we aim to get you peace of mind, and help you improve your operational agility to implement legal mandates, as you navigate a highly competitive and price sensitive environment.

If you are interested in learning more about the solutions mentioned, look at the links below:

SAP Document and Reporting Compliance

SAP Risk and Assurance Management

Sources:

(1) The state of new business building, McKinsey, December 2021

(2) Deloitte, Global Tax and the impact of BEPS on consumer business, Deloitte’s 2020 global survey on the OECD’s Base Erosion and Profit Shifting (BEPS)

(3) Plastic taxes: a guide to new legislation in Europe, February 2023

(4) SAP S/4HANA update for 2023 – Comply with new regulations and respond to the latest compliance trends with SAP Document and Reporting Compliance, October 2023

Shift to Remote, Continuous, and Risk-Adjusted Management with SAP Three Lines of Defense Package

2024-04-09T07:00:00.022000+02:00

With 90% of compliance leaders expecting evolving business, regulatory, and customer demands to significantly increase compliance-related operating costs, it is no surprise that half of them are already aiming to automate controls monitoring and management capabilities.

The Three Lines of Defense add-on package is designed to help RISE with SAP customers shift to remote, continuous, and risk-adjusted management that drives down risk and compliance costs and builds trust.

By embedding integrated solutions for internal control and compliance, enterprise risk management and internal audit into the very foundation of their SAP software landscape, organizations can automate tasks and decision-making, gain real-time visibility on their compliance status, and equip people to anticipate and respond to the risks standing in the way of achieving business objectives.

Managing risks, controls, and regulatory requirements directly in business operations and monitoring compliance status in real-time is key to supporting risk-based decision-making.

As part of the Three Lines of Defense add-on package, SAP Process Control and SAP Risk Management natively integrate with SAP S/4HANA, SAP Signavio, etc. and work together to automate continuous control and risk monitoring. Effortlessly supporting continuous, automated risk and compliance monitoring across systems and processes. With embedded rules, configurations, and intelligent monitoring capabilities these solutions assist in doing the hard work of detecting, predicting, and mitigating threats in real time and invoking exception processes, when needed.

Furthermore, real-time reporting allows organizations to demonstrate compliance status to stakeholders on demand, reducing the overall assurance effort.

By leveraging this single source of truth, SAP Audit Management further enables organizations to increase assurance and improve audit efficiency - and enables the audit teams shift their focus from providing basic assurance to delivering trusted insight and advice to the business.

With integrated solutions from the Three Lines of Defense add-on package, companies can increase transparency and standardization of their multiple compliance initiatives and focus on the processes and activities that are most important. By aligning value drivers, objectives, and high-impact risks, they can seize opportunities and mitigate risks promptly for increased profitability using instant access to crucial risk indicators.

If you are a RISE with SAP customer, you can benefit from this cost attractive package to optimize collaboration across all three lines, and ensure the reliability, coherence, and transparency of the information required for decision-making.

If you’d like to read more about this package and its components, then have a look at the following links:

Solution brief: Strengthening the Three Lines for Governance, Risk, and Compliance
Overview video: Integrated Risk and Controls Management for SAP S/4HANA
Individual product pages: SAP Process Control, SAP Risk Management and SAP Audit Management

Trustable AI thanks to - SAP AI Core & SAP HANA Cloud & SAP S/4HANA & Enterprise Blockchain 🚀

2024-04-11T12:51:09.466000+02:00

This blog is the seventh in the series and discusses what AI and and SAP and Enterprise Blockchain are, why they are so important for each other, and then takes a deep dive in to the SAP product oriented reference architecture of how to implement SAP AI Core and S/4HANA and Enterprise Blochchain.

What will it take to make AI trustable ?

tl:dr

SAP Artificial Intelligence SAP AI Core SAP HANA Cloud SAP S4HANA Enterprise Blockchain - atkrypto.io

Enterprise Blockchain is the Cyber Security for Enterprise AI. 🚀

This blog introduces the Enterprise Blockchain Wallet and Off-Chain data storage and demonstrates why it is so special and important for protecting the trustworthiness and reliability and integrity and originality of information and data, be patient and read on because the Enterprise Blockchain Wallet is something very special and enables us to protect large and unstructured data very simply and effectively and is one of the biggest reasons why an Enterprise Blockchain Database is so suited to protecting data for AI operations

The blog is going to break the subject down in to three sections:

Section 1.0: The What is it of SAP AI, and Enterprise Blockchain

Section 2.0: The Why is it, of SAP AI, and Enterprise Blockchain

Section 3.0: The How is it, of SAP AI, and Enterprise Blockchain

A huge amount has been written about both Artificial Intelligence and Enterprise Blockchain and there is no point to repeat everything here, so we will talk briefly about the subjects and then point to very useful resources for further reading, and focus our attention on why Enterprise Blockchain makes Artificial Intelligence trustable, and how to do it.

Section 1.0: The What is of SAP AI, and Enterprise Blockchain

What is Artificial Intelligence ?

What is the History of AI ?

and SAP has an amazing AI powered product roadmap, taking the product portfolio...

. from a System of Record

. through being a System of Engagement

. to being a System of Intelligence

What AI can do for the Enterprise, and where AI is going, massive opportunities are coming along, and it is happening all around us as we speak, this technology revolution is not on presentations, it is real and we can implement it and benefit from it right now, today. SAP's AI capabilities are growing by the day:

Like everything else we do in Enterprise IT,

AI is about Data

What is Enterprise Blockchain ?

Enterprise Blockchain is both:

. a Secure Store

. a Secure Communication Channel

McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time". If we just pause for a moment and let that sink in, and think about what that means, to Business Processes, to Collaboration, to System Resilience, we start to see what is so special about Blockchain Databases and Distributed Ledger Technology.

In these previous blogs, I made a deep dive in to what Enterprise Blockchain is and why we should be positioning it in our Enterprise Architecture:

Why I love SAP and Blockchain Databases and why you should too 🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain🚀

and in a nutshell, Enterprise Blockchain is:

. The Digital Transformation of Information Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

To wrap up this section:

. AI is about Data

. Enterprise Blockchain is about Security of Data

Section 2.0: The Why is it, of SAP AI, and Enterprise Blockchain

SAP say it themselves, building trust in AI, means the AI has to be:

. Relevant

. Reliable

. Responsible

What is AI's biggest risk ?

AI's biggest risk is that the Data behind the AI is not trustworthy. In the same way as asking the wrong person for directions can leave you going all around the houses, if the Data behind the AI, and this means the Models as well, has been changed/contaminated/modified/poluted/made unreliable, whether purposefully through malicious acts or cyber attack, or accidentally, the result will be AI insights which cannot be trusted, and the result of that could be catastrophic.

Gartner remind us of this, when they describe the 4 key initiatives to get your Enterprise AI ready, and number 2 is AI Cyber Security:

AI is about the Data

So, if we are going to do AI, then we need to care for and protect the Data that the AI is using.

Imagine, as described in the previous blog, when we let the Use Case find the Enterprise Blockchain, we have a Business Requirement, a Business Demand, to make AI trustable to make AI achieve as SAP put it, the three R's, Relevant, Reliable, Responsible:

In the US, NIST, the National Institute of Standards & Technology have a whole section dedicated to AI and risks with AI. The biggest risk to AI is the trustworthiness of the data:

When we look in our Enterprise Technology Standards, and we look for the Technology Standard in our Enterprise Portfolio which is positioned to bring the strongest protection to Data, we find the Enterprise Blockchain.

Comparison Enterprise Blockchain Database and Traditional Legacy Database - atkrypto.io

In the previous blogs, we have discussed in detail about the special characteristics of Enterprise Blockchain and just why it natively out of the box protects the integrity of data to a level that legacy database products cannot do, in a nutshell....

AI is about Data

AI is about the Data that goes in to the AI engine

This means AI depends on a Database or a Datastore

What kind of Database does AI need ? What capabilities does the Database for the AI Data need to have ?

1. It must not be possible to modify the Data in the Database which feeds the AI - the Database needs to be immutable

2. The Data in the Database, the integrity and originality of that Data must be protected to the highest level that is technically possible

3. The Data must be available with the highest availability, the Database must be resilient to attack

When we look in our Enterprise Technology Standards we find 1 Technology Standard in the Enterprise which has those capabilities, and that is..... Enterprise Blockchain

Enterprise Blockchain ticks those three boxes...

✅Immutable - tick that box

✅Integrity must be protected to the highest level - tick that box, thanks to the Enterprise Blockchain Hash Mechanism and the Enterprise Blockchain Consensus Mechanism

✅Highest level of resilience and availability - tick that box thanks to the Distributed and Decentralised nature of the Enterprise Blockchain

This is why, Enterprise Blockchain is the enabler of trustable outcomes from Enterprise AI.

atkrypto.io what is a blockchain

But there's more than that, AI, and especially during the AI Training, AI needs a lot of data, and that's why SAP AI Core uses SAP HANA Cloud (Data Lake) as the Data Source, because the volumes of data for training are big.

And this is why, in this blog we take the Enterprise Blockchain Technology story one level further and we introduce the:

Enterprise Blockchain Wallet

Off-Chain Data Storage

In the Enterprise Blockchain Platforms, the Enterprise Blockchain Wallet is used for Off-Chain storage of big data and in the following paragraphs we will explain why.

What is the Enterprise Blockchain Wallet, and what is Off-Chain Data Storage and why would we use them and why do we need them ?

As we have explained in a previous blog, the Enterprise Blockchain Database, the Distributed Ledger, can be looked at simply as a Database Table (which is replicated and synchronised across multiple Servers) and in principle it stores the Data like this:

Blockchain is a very simple form of database atkrypto.io

This is fine, and suited to what we call Structured Data, and as AWS nicely describe, Structured Data is information like words and numbers. This kind of data is perfectly suited to being stored in an Enterprise Blockchain Database and also a legacy Database. Examples of the data would Names, Addresses, Phone Numbers, Product Information etc.

But, AI Artificial Intelligence software, especially during the Learning requires large quantities of this information, this data, and in SAP AI Core the volumes, the amounts of data which are required for AI Learning are so big, and are often stored in what's called CSV, Comma Separated Values files, and these CSV files will are too big to be stored on the Enterprise Blockchain Database itself, and they are too big to be stored in a Legacy Database.

So, if we can't store the large CSV file in Enterprise Blockchain Database, then how, in an Enterprise Blockchain Platform do we store large files of Data ?

Voila.... bring in the Enterprise Blockchain Platform Wallet. The best Enterprise Blockchain Platform products include what is called the Enterprise Blockchain Platform Wallet, or to make it shorter, the Enterprise Blockchain Wallet.

The Enterprise Blockchain Wallet enables us to store large Data, like large Files safely and securely off the chain, or 'Off-Chain'.

But if we store the large Data files Off-Chain in the Enterprise Blockchain Wallet, then how do we also have them some how on the Enterprise Blockchain Database ?

The way this works is elegant, in any decent Enterprise Blockchain Platform, the Enterprise Blockchain Wallet location is completely configurable, and could be anywhere from SAP HANA Cloud (Data Lake), or for example multiple hyperscaler object stores, such as Amazon S3, OSS (Alicloud Object Storage
Service), SAP HANA Cloud, Data Lake, and Azure Blob Storage.

The configurable Enterprise Blockchain Wallet of the Enterprise Blockchain Platform looks like this:

Enterprise Blockchain Platform - Enterprise Blockchain Wallets - Configurable Enterprise Wallets - atkrypto.io

Ok, so we've got the AI Data stored in the (configurable) Enterprise Blockchain Wallet, but what about securing the AI Data ? Obviously the Enterprise Blockchain Wallet storage location has built in security, for example the SAP HANA Cloud, the AWS S3 Buckets, but we need more than the out of the box security of these products, the reason we are using the Enterprise Blockchain Database is because of the amazing security strengths that it natively out of the box has, and so, what about the Enterprise Blockchain Wallet, doesn't the Enterprise Blockchain Platform have some cool super hard way of protecting the data in the Enterprise Blockchain Wallet ?

Well yes it does, this is the magic of Enterprise Blockchain Database 'Off-Chain' storage in the Enterprise Blockchain Wallet. This is so unique to Blockchain Technologies.

What happens is this, when store data in the Enterprise Blockchain Wallet, the Enterprise Blockchain Platform software runs a hash algorithm over the data that we have stored and the data, and the large file gets hashed:

The data or the file in the Enterprise Blockchain Wallet gets hashed, and then, that hash is stored in the Enterprise Blockchain Database.

This means we now have a unique hash of that data or file, and if anybody or anything makes even the tiniest teeniest change to that data or file, next time we run a hash over that data or file the result will be different that the original hash which is safely stored in the Enterprise Blockchain Database and this is how we will know that the data has been changed and we cannot trust the Data and therefore we cannot use it for our Enterprise AI.

On the other hand, if just before we load the data in to the Enterprise AI from the Enterprise Blockchain Wallet, if we run a hash over the data and the hash result is the same as we have in the Enterprise Blockchain Database, then we will know we can trust the Data and we can use it in our AI and we will have trustable AI.

Enterprise Blockchain Wallet Data Hashes Stored in the Enterprise Blockchain Database - atkrypto.io

And this is why, for all of these reasons,

Trustable Enterprise AI depends on Data being stored in the Enterprise Blockchain

Outlier Ventures, in their AI Thesis, very nicely show how Enterprise Blockchain & Artificial Intelligence together solves the risks associated with AI alone:

To conclude this section, the Why to, of Artificial Intelligence and Enterprise Blockchain, Artificial Intelligence needs to be Reliable, Relevant, Responsible, for it to be Trustable.

Enterprise Blockchain, due to its native super strong security strength when used as a store of Data and Models for AI, enables AI to be Trustable.

Section 3.0: The How is it, of SAP AI, and Enterprise Blockchain

Now that we know why trustable Enterprise AI needs the Enterprise Blockchain Database to protect the integrity and originality of the Data and Models, how do we implement it today ?

Well that's easy, here are the ingredients and the recipe 😄

Ingredients, you're going to need:

Data Source(s) eg

S/4HANA and others

Enterprise AI Product

SAP AI Core

SAP AI Launchpad

Large Storage for Large Data and the Enterprise Blockchain Wallet

SAP HANA Cloud (Data Lake)

Enterprise Blockchain Platform

These are the basic ingredients, the data from the S/4HANA will be stored in the SAP HANA Cloud (Data Lake) which will also be the Enterprise Blockchain Platform (configurable) Wallet, the Enterprise Blockchain Platform, and then SAP AI Core to read the Data from the (SAP HANA Cloud - Data Lake) Enterprise Blockchain Platform Wallet and process it through Enterprise AI and turn it in to insights through the SAP AI Launchpad.

And your Technical Reference Architecture will look something like this:

SAP AI Core SAP S4HANA SAP AI Launchpad SAP HANA Cloud Data Lake Enterprise Blockchain Protection - atkrypto.io

And that's how you do it.

Wrapping up, conclusions:

. Trustable Enterprise AI depends on Data being stored in the Enterprise Blockchain

Enterprise Blockchain is:

. The Digital Transformation of Information Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

Enterprise Blockchain is both:

. a Secure Store

. a Secure Communication Channel

The configurable Enterprise Blockchain Wallet enables you to store Big Data 'Off-Chain' and the hashes of the Big Data are stored safely and securely on the Enterprise Blockchain Database.

So what are we waiting for ? Oh yeah, more use cases, ok, that will be the next blog.

What do you think, are the words AI, Blockchain, Web3, Distributed Ledger Technology, starting to appear in your Company's visions and technology visions ? What use cases are you looking at ? Let's chat about it in the comments.

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

Agile, Secure, and Compliant Business Operations Through Resilience

2024-04-16T00:52:00.653000+02:00

Succulents are highly resilient plants growing in arid areas with low rainfall. They soak up and retain water to get through dry seasons. They can survive even on mist and dew.

By Deb Drechsel, Global Head of Employee Awareness & Enablement, Global Physical Security and Jay Thoden van Velzen, Office of the CSO, SAP Global Security & Cloud Compliance

Recently, Anahita Thoms and Thomas Saueressig published an article on SAP News that strongly resonated. It asked the question, is supply chain innovation even possible in an era of tighter regulation? The article begins:

The world is experiencing a new, tougher business environment. Trade tensions, wars, climate change, and countless other disruptions are putting the brakes on a long and steady period of globalization. Given this growing uncertainty, companies must reconfigure global supply chains to improve their resilience.

Business leaders might assume that more regulation in such a volatile environment would hinder the innovation they require most at this time. However, we will argue smart and balanced regulation can serve as a catalyst for transformation.

While the article is clearly written from the perspective of how SAP solutions can help customers weather these challenges, SAP as a global software and cloud service provider must do the same.

Resilience

The resilient survive, not necessarily the strongest. The resilient know how to withstand and recover from adverse situations, or even thrive during rapid change. Birds and mammals made it through the asteroid impact 66 million years ago. The (non-avian) dinosaurs didn’t. Darwin’s “survival of the fittest” means being better adapted to one’s immediate local environment. When that environment is changing, the fittest are those that are most adaptable. That is, those that are most resilient.

Whether in business and technology operations or in physical- and cybersecurity, resilience is increasingly a factor. Business faces an uncertain business, geopolitical, regulatory, and environmental climate. The technology cycle has sped up, and on demand cloud infrastructure and cloud-native practices like Site Reliability Engineering (SRE) stress always-on service operations.

The rise in cyber threats, in particular ransomware, is focusing security teams on detection, response, and recovery, not just on protection. The impact of security incidents drives an increase in security-related regulation. The influence of DevOps and SRE is driving innovation in cloud-native security practices to scale security and compliance in cloud services.

In SAP, cybersecurity and physical security risks are managed by SAP Global Security & Cloud Compliance, with the support of colleagues throughout the organization in various technology and business functions. The Global Physical Security team is focused on staying resilient in our organization’s ability to withstand and recover from physical attacks, cyber incidents, or natural disasters. They monitor the ever-changing global threat landscape and associated risks and adjust our strategy accordingly. The measures taken to protect physical assets, people, and unauthorized access require maintaining as well as growing a resilient mindset from our organization and all security professionals.

When business, technology, cyber and physical resilience align and interact – as they must, to be truly resilient – we start to see overlaps, as in the Venn diagram below. It is in these petal-shape intersections that we find opportunity. But these petals are also where gaps will appear if they are not managed well and that could make the organization vulnerable.

Resilience “Flower” Venn diagram of intersecting resilience petals

Geopolitical and Climate Risks

Business models, operations and supply chains are realigning due to the impact of trade wars and sanctions, environmental disasters and climate change, and military conflicts and political instability. Organizations may be directly affected, or indirectly through delayed delivery times or higher insurance costs. Increased regulation and reporting requirements, as mentioned in the SAP News article linked above, add an additional burden to navigate.

Protests and civic activism can add another dimension. That also goes for cloud service providers. For instance, there is growing resistance to additional data centers due to concerns regarding the environmental impact of new data centers (Chile, Portugal, The Netherlands). Data centers consume much power and water, and that is only going to increase with the growth in the use of cloud services and AI.

Business Agility and Continuity

The intersection between business and technology is how technology enables the business to respond to these geopolitical and climate risks, as well as business, financial and market risks. Technology resilience is required for business continuity – that is, keeping the lights on and recover quickly. Cloud services and cloud-native technologies such as Kubernetes have made “always-on” models viable, as well as systems that scale with demand.

Technology resilience is also required to support the necessary business agility. That means that the technology should continuously renew and be adaptable to the needs of the business, rather than hold the organization back through legacy systems and processes. Technology must be an enabler of business resilience. Business AI will contribute to that.

Security and Compliance Risks

Cybersecurity teams set policies and provide governance, but IT operations and DevOps teams must configure and operate systems according to those policies and bring them in compliance. The intersection between technology and cyber is therefore where most of the security and compliance risks lie. The gap between security requirements and the execution to those requirements is where both adversaries and auditors cause you unpleasant surprises.

DevSecOps and good Software Development Lifecycle (SDOL) practices, Continuous Integration/Continuous Delivery (CI/CD) pipelines, enforced cloud guardrails and landscape scanning all help keep that security and compliance gap small and raise resilience, without impeding the agility of technical teams.

Among the main areas of business, technology, cybersecurity and physical security, cybersecurity is the least mature. Cybersecurity leaders often still stress defense over resilience. Often repeated dogmas like “Defenders have to be right all the time, attackers only once” illustrate this, as opposed to an approach that assumes breach and focuses on detection, response, and recovery.

The rise in ransomware attacks with business impact (in terms of possible ransoms paid, loss of business, and response and recovery costs) indicates that the networks of many organizations are vulnerable. Recent reports show that is also the case for cloud landscapes. Software supply chain attacks like the Solarwinds incident pose further challenges. In reaction, governments globally are intervening with stricter regulation and are pushing more responsibility on critical infrastructure and technology providers to have processes in place to meet security baselines.

Cyber Physical Risks

The cyber-physical petal is another intersection that could jeopardize the resilience of an organization. A classic XKCD illustration (538) shows the limits of cybersecurity controls in the face of physical threats. Leaked and stolen credentials are a known issue in cybersecurity. But Multi Factor Authentication (MFA) will not protect you if a sufficiently motivated adversary forces an employee into collaboration.

Any organization with remote and office workers, and traveling executives and representatives, must consider the cybersecurity downstream effects from any physical security incidents, besides the immediate safety of those employees. Meanwhile, in the current age of virtual job interviews, hiring managers must guard against bringing adversaries into their organizations. If they don’t, they may inadvertently support a sanctioned regime.

Cybersecurity incidents in critical infrastructure and critical business systems have caused disruption of operations in resorts, cities, healthcare, fuel distribution, and global shipping. These cases show how critical resilience is in providing organizations options on how to respond and recover.

Agile, Secure and Compliant Business Operations

As we have seen, technology, cybersecurity and physical security need to act in concert to support the business to survive and thrive in the current business climate. Cloud Infrastructure-as-a-Service (IaaS) is often chosen for the agility and flexibility to scale up as well as down as needed. IaaS providers have engineered resilience into their cloud platforms, which enables their customers to configure their systems as they require. While this increases agility, it also adds the complexity of cloud infrastructure configuration in addition to managing the workloads and applications.

With Software-as-a-Service (SaaS) providers that complexity for customers is reduced to the management of the applications only. The rise of enterprise SaaS providers as documented in Acceleration Economy’s Cloud Wars suggests that customers are increasingly comfortable moving to cloud services higher up the stack.

Like all organizations, cloud service providers must be resilient. Unlike their customers, they have the benefit of what Phil Venables, CISO of Google Cloud, has called the 'decreasing marginal cost of security’. Cloud service providers can scale the cost of security and compliance controls across many landscapes and customers, and therefore can afford larger teams, and manage a broader spectrum of threats and global regulations. That also applies to SAP.

However, as a technology and service provider of enterprise business solutions, SAP is uniquely positioned among cloud companies to enable agile, secure, and compliant business operations as well as business resilience. SAP supports customers with their geopolitical and climate risks, business agility and continuity, security and compliance risks, and cyber physical risks through both its solution portfolio of applications and its cloud services operations.

Necessity is the mother of invention, as SAP experienced itself in its ongoing cloud transformation. Growing uncertainty and regulation can be a catalyst for transformation, as the SAP News article argues we began with. That article ends with three customer examples:

Necessity often drives innovation, leading companies to invest in advanced technologies […]. Unilever’s commitment to traceability and transparency in its global palm oil supply chain demonstrates how compliance acts as a transformative force. Nestlé’s embrace of technology illustrates how businesses can enhance transparency, and resiliency, while ensuring compliance with evolving standards. And Grupo Nutresa’s procurement transformation shows how it’s possible to deliver efficiencies and generate more value while doubling down on sustainability with trading partners.

SAP is honored to support customers such as these in their cloud transformation and journey towards greater resilience.

“What Will SAP Basis Administrators Do Once We Move to RISE?” – Thoughts Following SAPinsider 2024

2024-04-20T00:01:08.232000+02:00

By Jay Thoden van Velzen, Technical Advisor, Office of the CSO

SAPinsider 2024 Las Vegas completed my world tour of similar events after Melbourne and Copenhagen, giving me a priceless opportunity to hear from customers in three very different regions. In Australia, many customers were already committed to the cloud and just wanted to make sure SAP understood the importance to their business we got it right. In Europe, many customers were more comfortable staying on-premise. In America, customers wanted to understand RISE with SAP S/4HANA Cloud (RISE) better but were clearly considering the option.

One customer question kept coming up in Las Vegas in both conference sessions and on the exhibition show floor: “What will SAP Basis administrators do after our organization moves to RISE?”. The short answer to that is “higher value activities”.

The question raised makes sense, when many responsibilities previously covered by Basis administrators or consultants in RISE are taken care of by the cloud provider. But since it is a trope in the cybersecurity profession that regardless how well we do, we’re never done, it is worth exploring the question further. Many on-premise ERP teams are struggling to keep up with complex landscapes. A move to RISE frees teams up for tasks that they couldn’t get to before.

Remaining Responsibilities

It is important to remember, though, that depending on your chosen edition and selected options, customers still must manage several remaining responsibilities. The RISE with SAP S/4HANA Cloud, private edition and SAP ERP, PCE Roles and Responsibilities document specifies clearly which services are standard, which are excluded and which are optional or additional services customers can choose to perform or have SAP manage for them. These services are broken down in five different categories.

Classification of five categories of services and responsibilities for RISE with SAP S/4HANA Cloud, private edition

While many infrastructure tasks are done by SAP, the administration, security, and compliance of the ERP system itself, including roles and authorizations, or implemented business processes remain with the customer. That also extends to other cloud services. The Recommended Security Configurations for SAP Cloud Services lists security recommendations guides for many SaaS cloud services for the parts that customers must manage.

Governance, Risk and Compliance

Beyond system administration, the next layer up the value chain is in the area broadly covered by SAP’s Governance, Risk and Compliance (GRC) portfolio as well as partner offerings in the space. This also includes identity and access management, fraud detection, and process compliance. An increase in cybersecurity and data privacy regulations, as well as trade regulations and sanctions, make this topic of growing importance. And that further extends into Environmental, Social and Governance (ESG) management.

The rise of Business Artificial Intelligence only further increases the need for governance around data residency, data privacy, and security compliance regulations to ensure that data is only stored and accessed for the right purpose by the right people.

GRC is often the first step for customers towards SAP security and compliance beyond system administration. We can go a lot further.

Integration and Extension Security

Custom code isn’t going away but is done differently in the cloud. To ensure that systems stay agile and can be more easily kept up to date, the first responsibility for SAP Basis administrators is to keep the core clean. They must also manage secure and compliant processes for integrations and extensions developed on the Business Transformation Platform (BTP).

The security of BTP extensions includes authentication and authorizations across integrated systems, with SAP or third-party solutions. It also includes threat modeling, code scanning, governance of code repositories, version control, testing, and deployment controls. That is, all the aspects of secure software development and operations lifecycles (SDOL).

Many security incidents exactly exploit weaknesses in the boundaries between systems. Threat modeling for that reason explicitly focuses on risks associated with such security scope boundaries. In a cloud landscape, that especially focuses on authentication, authorizations, and Application Programming Interface (API) security to ensure that integrations are done on a least-privilege basis, and don’t inadvertently break authorization concepts or data residency and privacy requirements. Code repositories must be governed by oversight through pull requests and code checks, as well as code reviews before being merged into a main development branch and deployed.

Such processes may already be in place in your organization for in-house software development. But it should be easier than ever to align them to an SAP cloud environment than with on-premise ABAP code and transports in its own separate world. This will help improve dialogue with your cybersecurity teams.

Threat Detection

Such a dialogue is important as often cybersecurity and SAP teams are not on the best of terms. Only in rare cases have customers integrated threat detection for SAP systems into their broader cybersecurity threat detection processes, and many have little time for threat detection even among SAP Basis administrators. SAP and the partner ecosystem provide solutions in this space, but these are not adopted universally. Integration of SAP logs and alerts into Security Incident and Event Management (SIEM) solutions or security data lakes with effective detections built on top of them that engage their Security Operations Center (SOC) is even less common.

Phishing or credential compromise detection and the SOC raises an alert, this provides a lead for SAP Basis administrators to hunt down associated threats in their ERP systems. However, this one-way threat detection doesn’t help against threats that originate in the SAP system, involve an insider threat, or abuse credentials deliberately to target customer SAP cloud solutions. The infrastructure is monitored by SAP, but threat detection within the application itself is customer responsibility and SAP cloud operations teams do not have visibility, access, or context at that level.

For that, organizations need a bi-directional information flow, where SAP Basis administrators provide the domain expertise as cybersecurity teams generally have no familiarity with the solutions. SAP Basis administrators are best equipped to find out whether something in the landscape is not right and understand the potential impact.

Respond and Recover

The domain expertise of SAP Basis administrators in security incidents is similarly important – if only to prevent the response to the incident to be less disruptive than the incident itself. A natural reaction from the SOC would be to contain the incident and reimage the landscape, as they would with laptops and phones, or servers and cloud infrastructure.

But an attacker inside an SAP solution itself, manifest itself through a high-privileged user or service account. Such privileges and authorizations are part of the metadata of the application. Customers can certainly request restoration of systems from backups as part of their cloud service contract. But depending on how quickly it took to detect the intrusion, a system recovery could restore the access of the malicious actor, while causing significant business disruption.

SAP Basis teams may have incident response plans for system outages, but these must be accompanied with run books for security incident response. There must be agreed plans and roles and responsibilities defined between the SAP Basis and SOC teams. Threshold levels that match the priority and severity of the incident with the business impact of containment and response measures must be agreed with organizational stakeholders.

Then these run books must be practiced and trained by SOC and SAP Basis teams during tabletop exercises, fire drills, and red teaming. Security incidents in SAP systems are bound to be rare – compared to phishing or social engineering attacks, for instance. An active incident is the wrong time to find out that you don’t have the right authorizations or business mandate to act or are forced to make decisions that affect business operations in the heat of the moment and under pressure.

From System Administration to Managing Security and Compliance

Cybersecurity (or information security, depending on one’s career trajectory) grew out of infrastructure, network, and system integration into its own practice of managing security and compliance risks. Identity and Access Management (IAM) or vulnerability management are commonly understood to be cybersecurity disciplines. In an SAP context, these are seen as SAP Basis administration activities.

With common infrastructure tasks disappearing with RISE with SAP S/4HANA Cloud, SAP Basis can evolve into managing the security and compliance risks of SAP cloud solutions. Since cybersecurity teams don't have the SAP expertise, SAP Basis administrators are the prime candidates to make their organizations more resilient against security and compliance threats.

More Information

IoT - Ultimate Data Cyber Security - with Enterprise Blockchain and SAP BTP 🚀

2024-04-22T11:07:39.454000+02:00

It wasn't that long ago that Cyber Security and Resilience translated to High Availability and Disaster Recovery. Driven by the Sensitivity, Confidentiality, and Availability requirements of the Data, Systems and Applications were built to have the highest possible availability. That requirement came from the times when an entire end to end Business Process ran in a single standalone Application.

Fast forward to today, end to end Business Processes can begin in one Application on one side of the world and pass through Applications somewhere else in the world and finish in Applications in an altogether different location in the world. The beginning of the Business Process can be Sensors and Things at the Edge, producing Data, Events, something has happened and triggered the Business Process.

This creates several problems:

Protect the Originality & Integrity of the Data - When the Thing, the IoT Sensor, let's say critical infrastructure, something like a Base Station in a Telco Network, or a piece of the Electrical Grid for a Utility Company, when the Thing, the IoT Sensor creates the piece of Data, a Record of something that just happened we need to make sure that piece of Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data

Moving the Data from the Edge to the SAP Application in the Cloud or DataCenter and at the same time Protect the Originality & Integrity of the Data - we need to get the Data from the Thing, the IoT Sensor, to the SAP Application in the Cloud or DataCenter and we need to be sure, to have surety that the Data which arrives in the SAP Cloud or DataCenter is exactly the same Data that was created at the Edge at the Thing, the IoT Sensor. If this Data gets changed in any way, we won't be able to trust the Business Processes and Insights which are depending on that Data. And so, in the activity of moving the Data we need to make sure that that piece of Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data

And so, here we are, the biggest threat to Enterprise SAP Applications is no longer the High Availability, the Server crashing, that's all under control and possible to take care of,

The biggest threat to IoT & Enterprise SAP Applications is Cyber Security and Cyber Attacks

A common thought is that a hacker, or cyber attacker wants to modify Data for their own financial benefit, for example change the destination bank account number for invoice payments, yes those threats are still there, but biggest threat is that a hacker or cyber attacker deletes or modifies Master and Transaction Data resulting that the Master and Transactional Data does not have integrity and cannot be used, and if the attacker succeeded to modify the Backup as well, then the Enterprise could be out of business for a long time trying to pick up the pieces and get up and running again.

The biggest threat to IoT & Enterprise SAP Applications is Cyber Attacks rendering the Master and Transaction Data un-trustworthy

And that's where the Enterprise Blockchain comes in, and this blog is going to explain why.

Ok let's go🚀

Welcome to the eighth blog in this series on Enterprise Blockchain and SAP. If you have been following the previous blogs then you'll be familiar with the blog template. We'll begin by talking about and framing the problem, in this case Data Cyber Security for IoT and SAP and then go in to identifying the enabling technology which will have the best capabilities and be the most appropriate to solving the problem all the way through to the reference solution architecture to be able to implement the solution.

The blog is going to break the subject down in to three sections:

Section 1.0: The What is it of IoT & SAP, and Enterprise Blockchain

Section 2.0: The Why is it, of IoT & SAP, and Enterprise Blockchain

Section 3.0: The How is it, of IoT & SAP, and Enterprise Blockchain

tl:dr

If you want to protect the originality and integrity and confidentiality of IoT data, from the Edge to Insights and SAP Business Processes, then the answer is an Enterprise Blockchain Database, where the Enterprise Blockchain Tenants are running on Edge Hosts/Servers and in the SAP BTP Business Technology Platform, enabling Enterprise Blockchain Database to protect the Data from the Edge Hosts/Servers to the SAP BTP.

IoT Internet of Things Edge Data Cyber Security and SAP Asset Performance Management BTP Protected by Enterprise Blockchain - atkrypto.io

[the finer technical details of getting the data from the Enterprise Blockchain to SAP Asset Management and S/4HANA will be clearer possibly after Sapphire Orlando in June. In the mean time there are a number of ways to get the Data in and out of the Enterprise Blockchain running on the SAP BTP Kyma Service]

Enterprise Blockchain is both:

. a Secure Store

. a Secure Communication Channel

Enterprise Blockchain is the Cyber Security for Enterprise IoT Data from the Edge to Insights 🚀

and now.... the long answer...

Section 1.0: The What is it of IoT & SAP, and Enterprise Blockchain

What is IoT Internet of Things ?

History of IoT

In 2021, there were over 10 billion IoT devices in the world, and by 2025, the IDC expects global data generation to exceed 73 zettabytes – which is equal to 73 trillion gigabytes. Although we can’t really quantify digital data in physical terms, we can say that if all that data were converted into 1990s floppy disks – and they were laid out end to end – they could go to the moon and back over 5,000 times.

[Source: What is IoT? The Future of Business | SAP]

What are some IoT applications?

Looking at IoT applications, which are sometimes described as use cases, can help ground the discussion about what IoT is. Broadly, IoT applications occur in one of nine settings.

Human health. Devices can be attached to or inserted inside the human body, including wearable or ingestible devices that monitor or maintain health and wellness, assist in managing diseases such as diabetes, and more.
Home. Homeowners can install devices such as home voice assistants, automated vacuums, or security systems.
Retail environments. Devices can be installed in stores, banks, restaurants, and arenas to facilitate self-checkout, extend in-store offers, or help optimize inventory.
Offices. IoT applications in offices could entail energy management or security for buildings.
Standardized production environments. In such settings, including manufacturing plants, hospitals, or farms, IoT applications often aim to gain operating efficiencies or optimize equipment use and inventory.
Custom production environments. In customized settings like those in mining, construction, or oil and gas exploration and production, IoT applications might be used in predictive maintenance or health and safety efforts.
Vehicles. IoT can help with condition-based maintenance, usage-based design, or presales analytics for cars and trucks, ships, airplanes, and trains.
Cities. IoT applications can be used for adaptive traffic control, smart meters, environmental monitoring, or managing resources.
Outside. In urban environments or other outdoor settings, such as railroad tracks, autonomous vehicles, or flight navigation, IoT applications could involve real-time routing, connected navigation, or shipment tracking.

Other real-world examples abound. IoT solutions are being used in myriad settings: in refrigerators, to help restaurants optimize their food-compliance processes; in fields, to track livestock; in offices, to track how many and how often meeting rooms are used; and beyond.

What is the economic impact of IoT?

The potential value of IoT is large and growing. By 2030, we estimate it could amount to up to $12.5 trillion globally. That includes the value captured by consumers and customers of IoT products and services.

The potential economic value of IoT differs based on settings and usages, with factory settings and human health applications representing outsize shares of this total. Factory settings could generate $1.4 trillion to $3.3 trillion by 2030, or just over a quarter of the total value potential. IoT economic impact in human health settings could reach around 14 percent of the total estimated value.

Another way of looking at IoT’s value is to explore use-case clusters (similar uses adapted to different settings). Some of the most common use cases account for a sizable share of IoT’s potential economic value:

operations optimization, which is basically making the various day-to-day management of assets and people more efficient (41 percent)
health (15 percent)
human productivity (15 percent)
condition-based maintenance (12 percent)

Other clusters include sales enablement, energy management, autonomous vehicles (the fastest-growing cluster), and safety and security.

[Source: What is IoT: The Internet of Things explained | McKinsey]

Like everything else we do in Enterprise IT,

IoT Internet of Things is about Data

What is Enterprise Blockchain ?

Enterprise Blockchain is both:

. a Secure Store

. a Secure Communication Channel

In these previous blogs, I made a deep dive in to what Enterprise Blockchain is and why we should be positioning it in our Enterprise Architecture:

Why I love SAP and Blockchain Databases and why you should too🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain 🚀

IoT Internet of Things and SAP - Enterprise Blockchain is the next generation Data Cyber Security Protection - atkrypto.io

and in a nutshell, Enterprise Blockchain is:

. The Digital Transformation of Information Security into Cyber Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

To wrap up this section:

. Iot Internet of Things is about Data

. Enterprise Blockchain is about Cyber Security of Data

Section 2.0: The Why is it, of IoT & SAP, and Enterprise Blockchain

So, why does IoT, Internet of Things, in the Enterprise IT, when implemented in conjunction with SAP Applications need Enterprise Blockchain ?

IoT is about Data, and the Data in most cases originates from the Edge and outlying parts of the Network.

The problem is the Cyber Security of getting the Data from the Edge and outlying parts of the Network to the safe zones of the SAP Cloud and yours or SAP's DataCenters.

IoT's biggest risk is that the Data coming from the IoT Devices is not trustworthy. In the same way as asking the wrong person for directions can leave you going all around the houses, if the Data coming from the IoT Devices, has been changed/contaminated/modified/poluted/made unreliable, whether purposefully through malicious acts or cyber attack, or accidentally, the result will be IoT's Data insights which cannot be trusted, and the result of that could be catastrophic. Just imagine not being able to trust the temperature of refrigeration during pharmaceutical and food production !

If we cannot protect and the originality and integrity of IoT Data, secure it, then how can we trust IoT Data ?

As Mckinsey & Company say:

IoT is about the Data

So, if we are going to do IoT and include IoT Data in our Business Processes and Insights, then we need to care for and protect the Data that is coming from IoT Devices.

Imagine, as described in the previous blog, when we let the Use Case find the Enterprise Blockchain, we have a Business Requirement, a Business Demand, to make IoT Data trustable.

Comparison Enterprise Blockchain Database and Traditional Legacy Database - atkrypto.io

IoT is about Data

IoT is about the Data that goes in to the SAP Applications in the Cloud and Data Centers

This means IoT Device Data depends on a Database or a Datastore

What kind of Database do IoT Devices produces ? What capabilities does the Database for the IoT Devices Data need to have ?

1. It must not be possible to modify the Data in the Database which comes from the IoT Devices - the Database needs to be immutable

2. The Data in the Database, the integrity and originality of that Data must be protected to the highest level that is technically possible

3. The Data must be available with the highest availability, the Database must be resilient to attack

When we look in our Enterprise Technology Standards we find 1 Technology Standard in the Enterprise which has those capabilities, and that is..... Enterprise Blockchain

Enterprise Blockchain ticks those three boxes...

Immutable - tick that box

Integrity must be protected to the highest level - tick that box, thanks to the Enterprise Blockchain Hash Mechanism and the Enterprise Blockchain Consensus Mechanism

Highest level of resilience and availability - tick that box thanks to the Distributed and Decentralised nature of the Enterprise Blockchain

This is why, Enterprise Blockchain is the enabler of trustable outcomes from Enterprise IoT Devices' Data.

atkrypto.io what is a blockchain

But there's more than that, IoT Devices can produce a lot of data, and the volumes of data can be big.

And this is why, in this blog we take the Enterprise Blockchain Technology story one level further and we introduce the:

Enterprise Blockchain Wallet

Off-Chain Data Storage

In the Enterprise Blockchain Platforms, the Enterprise Blockchain Wallet is used for Off-Chain storage of big data and in the following paragraphs we will explain why.

What is the Enterprise Blockchain Wallet, and what is Off-Chain Data Storage and why would we use them and why do we need them ?

Blockchain is a very simple form of database atkrypto.io

But, IoT Devices can produce a lot of Data, for example, there could be photographs proving that general waste was tipped at the correct certified location, photographs and in large volumes would be too big to be stored on the Enterprise Blockchain Database itself.

And that's ok, Enterprise Blockchain Platforms are ready for that, and have been designed to store both Structured Data and Data which is in files which are so big that they cannot be stored in the Enterprise Blockchain Database itself, for example the photographs from a Waste Truck's onboard camera proving that waste was responsibly tipped in the correct location and taken at the same time as recording GPS location coordinates proving the location of the Waste Truck.

So, if we can't store the large photographs files in large quantities to the Enterprise Blockchain Database, then how, in an Enterprise Blockchain Platform do we store large files of Data ?

The Enterprise Blockchain Wallet enables us to store large Data, like large Files safely and securely off the chain, or 'Off-Chain'.

But if we store the large Data files Off-Chain in the Enterprise Blockchain Wallet, then how do we also have them some how on the Enterprise Blockchain Database ?

The configurable Enterprise Blockchain Wallet of the Enterprise Blockchain Platform looks like this:

Enterprise Blockchain Platform - Enterprise Blockchain Wallets - Configurable Enterprise Wallets - atkrypto.io

Ok, so we've got the IoT Data stored in the (configurable) Enterprise Blockchain Wallet, but what about securing the IoT Data ? Obviously the Enterprise Blockchain Wallet storage location has built in security, for example the SAP HANA Cloud, the AWS S3 Buckets, but we need more than the out of the box security of these products, the reason we are using the Enterprise Blockchain Database is because of the amazing security strengths that it natively out of the box has, and so, what about the Enterprise Blockchain Wallet, doesn't the Enterprise Blockchain Platform have some cool super hard way of protecting the data in the Enterprise Blockchain Wallet ?

Well yes it does, this is the magic of Enterprise Blockchain Database 'Off-Chain' storage in the Enterprise Blockchain Wallet. This is so unique to Blockchain Technologies.

The data or the file in the Enterprise Blockchain Wallet gets hashed, and then, that hash is stored in the Enterprise Blockchain Database.

On the other hand, if just before we load the data in to the SAP Enterprise Applications, eg SAP Asset Performance Management and SAP S/4HANA, from the Enterprise Blockchain Wallet, if we run a hash over the data and the hash result is the same as we have in the Enterprise Blockchain Database, then we will know we can trust the Data and we can use it in our SAP Applications and we will have trustable IoT Data.

Enterprise Blockchain Wallet Data Hashes Stored in the Enterprise Blockchain Database - atkrypto.io

And this is why, for all of these reasons,

Trustable Enterprise IoT Data depends on Data being stored in the Enterprise Blockchain

But that's not the end of the Why IoT Data needs Enterprise Blockchain.

As we showed at the beginning of the blog in this picture:

IoT Internet of Things Edge Data Cyber Security and SAP Asset Performance Management BTP Protected by Enterprise Blockchain - atkrypto.io

As the picture shows, we have an Enterprise Blockchain Database Tenant installed on a Server Host at the Edge of the Network AND we have an Enterprise Blockchain Data Tenant installed on the SAP BTP Kyma Runtime.

The consequence of this is that we have a distributed Enterprise Blockchain Database table which stretches from the Edge of the Network where the IoT Devices are all the way across the Network to the SAP BTP and DataCenter.

This means we have Enterprise Blockchain Data Protection from the source where the IoT Devices are to the Insights and Business Processes where the SAP Applications are.

We have taken the Enterprise Blockchain to the Data at the source at the IoT Devices instead of taking the IoT Device's Data across all of the Networks to the safety of the SAP BTP and DataCenter. This is because we need to store the Data in the Enterprise Blockchain as close as possible to the source of the Data. The closer the Enterprise Blockchain Tenant is to the source of the Data, the safer the Data will be, it's as simple as that. Enterprise Blockchain is the next generation Cyber Security for IoT Data, and we need to minimise the amount of exposure IoT Data has to previous generation security technologies and approaches.

And this is why we say, Enterprise Blockchain is a Secure Communication Channel, because instead of integrating Applications sending and replicating Data across Networks, we are sharing the Data across the Enterprise Blockchain and the Enterprise Blockchain is the Secure Communication Channel.

IoT Internet of Things and SAP - Enterprise Blockchain is the next generation Data Cyber Security Protection - atkrypto.io

To conclude this section, the Why to, of IoT and Enterprise Blockchain, IoT Data needs to Trustable.

Enterprise Blockchain, due to its native super strong security strength when used as a store of Data enables IoT Data to be Trustable, and the Enterprise Blockchain Software needs be installed as close as possible to the source of the IoT Data, as close as possible to the IoT Devices.

Section 3.0: The How is it, of IoT & SAP, and Enterprise Blockchain

Now that we know why trustable Enterprise IoT needs the Enterprise Blockchain Database to protect the integrity and originality of the Data, how do we implement it today ?

Well that's easy, here are the ingredients and the recipe...

Ingredients, you're going to need:

Data Source(s) eg

IoT Devices which are either REST or MQTT (this could be other protocols and transfer mechanisms depending upon the required Adapters)

SAP and IoT IoT Devices sending Data to MQTT Broker in the Edge Host Instance of the Enterprise Blockchain Platform Database Tenant - atkrypto.io

SAP and IoT IoT Devices sending Data to REST Endpoint in the Edge Host Instance of the Enterprise Blockchain Platform Database Tenant - atkrypto.io

Large Storage for Large Data and the Enterprise Blockchain Wallet

SAP HANA Cloud (Data Lake)

Enterprise Blockchain Platform and specifically one which is capable of running Tenants as close to the Source of the IoT Data as possible at the Edge. We do NOT want to send the IoT Data across the Internet to a Blockchain somewhere in the Cloud, that would defeat the object of the exercise.

These are the basic ingredients, the data from the IoT Devices will be stored either Off-Chain in the SAP HANA Cloud (Data Lake) which will also be the Enterprise Blockchain Platform (configurable) Wallet, or On-Chain in the Enterprise Blockchain Platform Database Ledgers, this Enterprise Blockchain Database Ledger will be running from the Edge to the SAP BTP and DataCenters and then SAP Applications like SAP Asset Performance Management and SAP S/4HANA will be able use the Data in Business Processes and Insights.

And your Technical Reference Architecture will look something like this:

IoT Internet of Things Edge Data Cyber Security and SAP Asset Performance Management BTP Protected by Enterprise Blockchain - atkrypto.io

And that's how you do it.

Wrapping up, conclusions:

. Trustable Enterprise IoT depends on Data being stored in the Enterprise Blockchain at the Edge and in the SAP BTP

Enterprise Blockchain is:

. The Digital Transformation of Information Security to Cyber Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

Enterprise Blockchain is both:

. a Secure Store

. a Secure Communication Channel

The configurable Enterprise Blockchain Wallet enables you to store Big Data 'Off-Chain' and the hashes of the IoT Data are stored safely and securely on the Enterprise Blockchain Database.

So what are we waiting for ? Oh yeah, more use cases, ok, that will be the next blog.

What do you think, are the words IoT, Blockchain, Web3, Distributed Ledger Technology, starting to appear in your Company's visions and technology visions ? What use cases are you looking at ? Let's chat about it in the comments.

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

All of this makes atkrypto,io the DePIN Decentralised Physical Infrastructure Network solution for Enterprise.

atkrypto is one of the Next20 startups being featured at TM Forum's DTW Ignite in Copenhagen in June

If you will be at DTW24 come and talk to us about Cyber Security of SAP Data with Enterprise Blockchain.

Behind the compatibility - What are the compatibility means between GRC and the plugins

2024-04-22T11:08:52.927000+02:00

GRC Access Control have many feature which requires to collect information or change/provision information in your plugin systems. To do so, you need to implement an additional functionality to them what we call Plugin component. Depends on the type of the plugin system, it can be a standard ABAP based Add-on (GRCPINW) with additional features for ERP systems (GRCPIERP), or it can be a solution for HANA Database (HCOGRCPI). The other plugins are mostly handled by the main GRC system using the appropriate API of the plugin. To have a stable and reliable landscape you need to regularly update these components with corrections and based on our basic suggestion you should upgrade them at least once a year. You also need to ensure that your plugins are compatible with the main GRC system. But what compatibility means? Is it just the Service pack level what Note 1352498 or Note 2487192 suggests, or there is something else?

In a simple way what the Notes describes are true. Service Packs will always be compatible to each other, and if you just implement or upgrade your system it gives an easy way to achieve the compatibility. On the other hand the real criteria of the compatibility is not the number of the SP, it is what we call codebase equivalency. During a usage of a functionality the main GRC system and the plugin codes are often communicating with each other and what we need to ensure is the communication works the same way using the same signs and codes. In reality no matter what Service Pack are implemented to you plugin system, if this set of communication rules are the same. Compatibility can be reached by implementing the same set of Notes as well, however determining the right ones are much harder then simply implementing the same Service Pack.

Lets see an example of what we call code base equivalency and why the compatibility is important. With SP 21 the Firefighter Session management changed and a more secure and reliable option is introduced. Part of these changes a completely new locking mechanism was required which not allows to use the same Firefighter IDs by different Firefighter Users at the same time. The initial version of this process used already existing objects and tables to lock the Firefighter ID. This worked properly, unless the database containsed remnants of old and inconsistent data. To resolve it Note 3408121 was introduced which provided a new locking interface and dedicated tables to ensure proper locking. This Note is part of SP 24 and it contains coding changes in both GRCDND_A and GRCPINW as well. If you use just only Centralized Firefighter, then you need to implement it only on your main GRC system, if you use Decentralized Firefighter, then you need to have in both the main GRC system and in your plugins as well to have the compatibility. Why? Because it changes the way how the locking works and this need to be the same both the Centralized environment and in the Decentralized one as well. If you just implement it on your main GRC system you will see inconsistent behavior in the Decentralized Firefighter Logon Pad and vice versa if you just implement it on the plugin. This is an example of the code base equivalency.

Now upgrade your main GRC system to SP24 (which already contains the coding changes of the above Note), and lets just implement this Note to your plugin system. Now an older SP level of your plugin will also be code base compatible with the main GRC system, even if the SP levels are different. (Of course by implementing just this single Note will not made it fully compatible for every functionality, however this particular locking mechanism will be compatible with each other.) If you would just update your plugin system to SP24 and leave the main GRC system on a lower SP level but implement the Note to your main GRC system then the compatibility would be also achieved (with the same limitation as in the previous case).

The compatibility is not (necessary) means that you need to have the same Service Pack level and you can have even a higher SP levels on your plugin system as well, if and only if, the compatible set of Notes are implemented to the lower-leveled system as well.

Implementing the same Service Pack level fulfill the requirement for compatibility without any extra effort. It is the easiest way to have it, however it is not the only one, and you don't need to be on the same Service Pack level to have the same code base and have compatibility.

GRC Tuesdays: Takeaways from the 2024 Internal Controls, Compliance and Risk Management Conference

2024-04-23T07:00:00.021000+02:00

On March 6th and 7th, TAC Insights and SAP brought together the SAP for Internal Controls, Compliance and Risk Management and the SAP for Cyber Security and Data Protection events under one roof in Brussels and into one single event under the theme RISE with SAP GRC.

We were very fortunate to have many customers join us to share their stories on enterprise risk management, control automation, cross-application segregation of duty risk management, security monitoring, and much more.

In today’s blog, I wanted to get exclusive insights from the keynote speakers and the conference chairs on what they heard during this conference and their perspective.

I thought I would start with Marie-Luise Wagener-Kirchner and Vishal Verma – who delivered the opening keynote. Marie-Luise was also co-chair on the internal control, compliance, and risk management track.

Thomas: During your keynote, you shared SAP’s key focus areas for the next 18-24 months. What would you say were the roadmap items that resonated the most with the audience?

Marie-Luise: I believe the fact that we are here to stay and continuously invest into our solutions. Highlighting recent innovations as well as outlining the exciting use cases we are planning to deliver together with an outlook on our GRC 2026 release where we plan to further harmonize our GRC solution portfolio.

Vishal: Clarity on “RISE with SAP” program that takes enterprises on a transformation journey that’s tailored exactly to their needs, and how SAP Solutions for GRC fits well with it. Audience also liked the way forward for SAP Identity Services and planned collaboration with Microsoft Entra.

Since we finished the first day with a live demo illustrating how SAP systems are targeted by passionate hackers (with the help of Google!), I thought I would ask Vincent Doux, chair of the cyber security and data protection track about what concerns companies the most and what they are doing to protect their landscape.

Thomas: Presenters all highlighted the increasing number of attacks they are experiencing on all IT systems. But from what you have heard during the event, would you say that the level of attack sophistication has increased or is it relatively similar vectors and patterns year over year?

Vincent: Right from the live demonstration on how SAP systems can be targeted by hackers with relative ease, it has been a real eye-opener about the level of sophistication in cyberattacks today. Existing SAP security measures play a crucial role in defending against common vulnerabilities and exposure patterns. However, the complexity and expertise in these attacks, unfortunately, are seeing a significant increase. Our customers' testimonials, be it BP, SANOFI, or GSK, strongly seconded this sentiment. They brought diverse perspectives on the challenges they've faced and how SAP's GRC & Security solutions have been instrumental in their defense strategy. One major observation across all testimonies was the need for a robust customized security strategy. Leveraging SAP's security solutions, they could maintain their competitive edge by preventing security incidents, ensuring data protection, and system integrity. The goal has always been to make sure that we're not just reactive but proactive. As our event theme suggests – RISE with SAP GRC, the emphasis is on staying ahead, innovatively addressing evolving threat vectors, and continuously improving the robustness of the security processes. Our job is to anticipate, adapt, and ensure that SAP security framework evolves faster than the threat landscape.

Thomas: From what organizations have shared on stage and your breakout discussion, what are companies concentrating on to protect against these threats?

Vincent: From the discussions, it is clear that our client organizations are focusing on three crucial areas. First is strengthening their internal controls and compliance through tools like SAP's GRC 3 Lines of Defense platform. Second, they are actively identifying and addressing vulnerabilities for proactive threat management in the SAP application layer and not only in the IT infrastructure. And lastly, they are creating a security-aware culture through regular trainings and simulations to involve not only IT population but also the business users. These concerted efforts ensure that they are well-prepared to combat any cybersecurity threats.

Michael Rasmussen shared an insightful session on the future of GRC with Business-Integrated GRC, “the next generation of GRC technology with a view focused on performance” and where “GRC becomes an integrated part of the business management platform”. In my opinion, a perfect topic to discuss with the 2 co-chairs of the internal controls, compliance, and risk management track – Marie-Luise Wagener-Kirchner and Michael Heckner!

Thomas: Within Business-Integrated GRC, Michael Rasmussen – GRC Analyst & Pundit at GRC 20/20 Research, mentioned Artificial Intelligence to enhance GRC capabilities but also cited the rising importance of environmental, social and governance (ESG) as key considerations. From what you have heard from customers, is work already ongoing to address these matters or are we still at the investigation and discovery phase?

Marie-Luise: While our customers heavily invest in smartness and automation, ESG is still closely monitored also with regards to upcoming requirements. Our customers have shared interesting use cases for Robotic Process Automation (RPA) and how they have built in internal controls to ensure stabilized business processes, they also shared insights in their reporting dashboards to foster clever decision making as well as their continued investments into smart automated controls.

Michael: I do see an interest in both, AI and ESG. Most of our customers, and at all levels, are currently enquiring about getting help from AI for various risk and compliance tasks. AI clearly is currently at the top of its hype cycle. What is often overlooked is that the repetitive, mundane, manual GRC tasks can already today be automated with advanced GRC platforms like SAP GRC towards continuous monitoring. Taking the human labour – and human error – out of the equation. AI will certainly add another level to it, but the available capabilities are not yet fully utilized.
ESG is a different story. Here the ESG-focused specialists of course see the common requirements between traditional GRC processes and ESG processes. Both ESG and GRC processes aim to ensure that organizations operate in a responsible and sustainable manner. They both involve assessing and managing risks, complying with regulations and standards, and monitoring performance. Additionally, both ESG and GRC processes require organizations to establish robust governance structures and frameworks to effectively manage and report on their activities. By integrating ESG and GRC processes, organizations can enhance their overall sustainability, risk management, and compliance efforts, leading to improved long-term performance and stakeholder trust.

Finally, in his closing keynote “A Future Beyond Comprehension”, Chris Johnston - Head of Finance and Risk Customer Solution Advisory EMEA-North at SAP, gave us a lot of reasons to hope for a very exciting future powered by AI. I therefore wanted to finish this blog on a similar positive mindset and asked the colleagues for a few words on their expectations for top GRC advances in the years to come.

Thomas: What technological progress do you think we can expect for GRC in the years to come?

Marie-Luise: Integration, smartness, and automation. Customer landscapes will remain and even become more heterogenous and technically challenging, thus requiring integration to achieve and sustain a holistic overview of business risks and their mitigations. Smartness with the different flavours of AI will be accompanied by automation to reduce complex manual tasks and to support the end-users in their daily work.

Vincent: In the future, we can expect generative AI and machine learning to revolutionize the GRC landscape with advancements in risk detection and automated compliance. Additionally, we’ll see more integration between GRC solutions and business processes for a unified view. Plus, as ESG considerations become prioritized, companies will leverage technology to effectively manage these. Overall, GRC is poised to become more efficient, integrated, and responsive to social responsibility.

Michael: I do see an increasing adoption of emerging technologies ranging from robotic process automation and continuous monitoring all the way to applying artificial intelligence. These technologies will enable more efficient and effective risk assessment, compliance monitoring, and governance processes.
While this will provide enhanced risk intelligence, we will also need to keep a close watch on emerging risks, esp. with new technologies like AI.
Overall, new technologies like AI will help to identify patterns, detect anomalies, and provide real-time insights in an unprecedented way.

If you attended the conference, I would be very interested in reading your comments either in this blog or on Twitter @TFrenehard

And it you couldn’t attend in 2024, I hope that you will consider joining us next year!

If you are interested in learning more about SAP solutions for Governance, Risk, and Compliance, feel free to fill-in the demo request form!

INFLUENCE THE DEVELOPMENT OF SAP ENTERPRISE THREAT DETECTION, CLOUD EDITION

2024-05-03T06:40:10.948000+02:00

Introducing influence page for SAP Enterprise Threat Detection, cloud edition.

The SAP Enterprise Threat Detection product team are inviting customers and partners to share their feedback and ideas to enhance our solution.

On SAP Enterprise Threat Detection, cloud edition Influence page you can see all submitted requests, submit your improvement requests, vote and comment on other ideas.

The rationale and advantages of a customer influence page include:

Augmenting customers engagement and influence on product features.
Improving product/services using meaningful customer insights.
Cultivating an engaged community.
Serving as a central platform for customer suggestions and fueling innovation.

The product team regularly evaluates the ideas and considers them for roadmap planning. Votes help to priorities ideas along with other important selection criteria such as:

DESIRABILITY: How many customers voted for this? How many customers will benefit from it?
VIABILITY: Is this Improvement Request globally relevant? Is this in alignment with SAP’s strategy for the product?
FEASIBILITY: Is the development effort realistic? Is this request achievable within the product’s architecture?

While this page is mainly for the public cloud edition, for private cloud and on-premise versions feel free to propose integration-related ideas.

Follow the steps below to get access and start sharing your enhancement ideas:

Go to SAP Enterprise Threat Detection, cloud edition Influence page.
- In case you are a new user, create a user account using S-User-ID and accept the Terms of Use. Once the user is created you activate SSO and can access without any interruption.

Follow the session to get notified of new Improvement Requests and blogs.
Vote and comment on Improvement Requests posted by other customers/ partners.
Submit new Improvement Requests.

You can also check out the videos\link below, if you wish to learn more about SAP Continuous Influence and how to submit and manage improvement requests:

Please reach us at SAP-ETD@sap.com in case of any issue.

We look forward to seeing your ideas and further improve our software as we move forward.

Threat Actors targeting SAP Applications

2024-05-03T07:57:35.500000+02:00

Last week, Onapsis and Flashpoint released a report describing the evolution of the Treat Landscape around SAP Applications, including the intersection of SAP and Ransomware. Some of its highlights include a 490% increase of the mentions to SAP exploits or vulnerabilities across the open deep and dark web from 2020 to 2023, or a whopping 400% increase in the price or an Remote Command Execution exploit for SAP Applications from August of 2020 to April of 2024.

These Threat Intelligence indicates that Threat Actors of all types understand how to target SAP technology, by exploiting SAP CVE(s), exfiltrating financial reports from SAP Applications, performing financial fraud over extended periods of time, or even through the execution of Ransomware, which also targets SAP Applications and data. Some examples of these Threat Actors are APT10, a state sponsored actor, FIN7/FIN13, which are financially motivated Threat Actors or Cobalt Spider, a cybercriminal group.

This is an effort moving in the direction of helping SAP Customers tackle cybersecurity threats such as active cyberattacks or ransomware, as done in the past jointly with SAP:

So as SAP Customers, what should we do?

In short, Vulnerability Management, Threat Detection and Threat Intelligence should integrate and incorporate SAP Applications.

Vulnerabilities and misconfigurations affecting SAP are used by Threat Actors to target SAP Applications, so SAP Customers should have proper vulnerability management programs addressing vulnerabilities and issues in a timely way. There are specific vulnerabilities and risks that were identified as part of this research so those individual CVE(s) and misconfigurations are among the ones we should prioritize. Having said that, SAP releases patches periodically (second Tuesday of every month) and we should be able to process them and react accordingly. As an example, these are the patches released by SAP on April 2024: SAP Security Patch Day – April 2024
Threat Intelligence tailored to SAP Applications should be consumed and integrated into Security Operation Centers, giving defenders the right signals to protect these applications before the bad guys act. Besides this recently released report, in the past, CISA has released a number of alerts, warning SAP customers about a number of different threats:
Feeds of logs and audit trails should be integrated into existing continuous monitoring programs to detect when SAP vulnerabilities are being exploited, SAP users are compromised or any other type of threat is affecting SAP Applications. These types of signals are extremely important to understand what happens through an SAP Application and to proactively detect potential threats.

If you are interested on reading more of this research, the report is available for download at both Onapsis and Flashpoint sites (SAP community policies do not allow to add the link directly on this blog).

GRC Tuesdays: Automate compliance with anti-forced labour regulations

2024-05-07T07:00:00.014000+02:00

Over 6 years ago now, I posted a blog GRC Tuesdays: Combating Modern Slavery—It’s More Than Compliance, It’s Ethics! mentioning that many countries across the globe were reviewing their response to exploitation in supply chains with parliamentary debates on new regulations coming into addition/replacement to what was already in place such as Dodd-Frank Act’s in the United States that rules on conflict mineral disclosure, the UK’s Modern Slavery Act, Netherlands’ Child Labour Due Diligence Law and France’s law imposing due diligence to prevent human rights abuses in supply chains.

This topic is becoming more and more prominent and forced labour is an integral part of “Erosion of human rights”, one of the key risks cited by the World Economic Forum in its Global Risks Report 2024 published earlier this year:

When discussing Environmental, Social, Governance (ESG) concerns with organizations, there are divergence in points of view of what needs to be done to implement the right processes – especially when it relates to reporting on metrics. There are even divergences on whether regulators around the globe will effectively enforce all the proposed legislations. But there is one ESG topic where I see a consensus: combatting forced labour is a necessity. Regardless of the industry or geography. And it seems that the recourse to legislation I had hinted to 6 years ago is now adding further pressure.

What is forced labour?

When defining forced labour, most regulatory bodies refer to the definition by the International Labour Organization from its June 1930 Forced Labour Convention: “forced or compulsory labour shall mean all work or service which is exacted from any person under the menace of any penalty and for which the said person has not offered himself voluntarily”.

Further to that, the International Labour Organization has developed indicators that individually or in conjunction, can indicate a forced labour situation:

Abuse of vulnerability
Deception
Restriction of movement
Isolation
Physical and sexual violence
Intimidation and threats
Retention of identity documents
Withholding of wages
Debt **bleep**
Abusive working and living conditions
Excessive overtime

Why should you care?

Let’s start with the obvious: it’s ethics!

As stated by the US Customs and Border Protection (CBP) quite eloquently: “Forced labor is a violation of basic human rights” and “Eradicating the use of forced labor is a moral imperative”.

As a matter of fact, the CBP has been tasked not only with identifying products made by forced labour and preventing them from entering the United States, they are also engaging on stopping them from being made in the first place.

And the United States are not the only country focusing on this matter. As listed in introduction, some European countries already had national legislation. But, on 23 February 2022, realizing that “voluntary action does not appear to have resulted in large scale improvement across sectors”, the European Commission adopted a proposal for a Directive on corporate sustainability due diligence with the aim “to foster sustainable and responsible corporate behaviour and to anchor human rights and environmental considerations in companies’ operations and corporate governance”. The intent here is to provide a harmonised legal framework in the European Union, creating legal certainty and level playing field.

These rules that are expected to come into force around 2027 and fines for breaching the rules could be as much as 5% of a company’s global turnover.

And more geographies are following suit especially since “Decent work and economic growth” is one of UN Sustainable Development Goals (#8) with a dedicated target to “Take immediate and effective measures to eradicate forced labour, end modern slavery and human trafficking and secure the prohibition and elimination of the worst forms of child labour”.

What can you do about it?

Eradicating forced labour won’t be achieved by individual organizations all by themselves, of course. And there is no single bullet (or tool) that will solve the issue on day 1 and ensure the company is compliant with the various regulations.

But there are steps that organizations can take. And technology and data traceability play a significant role in supporting anti-forced labour compliance. By providing monitoring capabilities and traceability of transactions, technology increases transparency of the supply chain as highlighted by KPMG in a dedicated webinar: Forced Labor Compliance Using SAP GTS

During this session, Frances Xing – Managing Director, Trade & Customs, Global Trade Technology, KPMG US, Laura Clawson – Senior Manager, Tax, Core ESG Team, KPMG US and Olesia Melnyk – Manager, Tax, Trade and Customs, KPMG US illustrated how SAP Global Trade Services could be leveraged to support compliance with anti-forced labour regulations, with a special focus on the Uyghur Forced Labor Prevention Act (UFLPA):

In summary, during the webcast, the KPMG thought leaders highlighted a few use cases including:

Utilizing sanctioned party list screening functionality to screen customers, suppliers, and other parties
Leveraging preference supplier solicitation functionality to effectively solicit and manage supplier solicitations for documentation and evidence required by Customs authorities
Screening transactions against forced labour indicators (HTS classification, country of origin, others)
Building robust reports to make an informed decision on forced labour blocked transactions

What about you, how does your company prepare for these regulatory requirements? I look forward to reading your thoughts and comments either on this blog or on Twitter @TFrenehard

And if you are interested in learning more about SAP solutions for Governance, Risk, and Compliance, feel free to fill-in the demo request form!

B2B Business Processes - Ultimate Cyber Data Security - with Blockchain and SAP BTP 🚀

2024-05-07T09:54:43.546000+02:00

B2B Business Processes - there are many Business Processes which cross Company and Organisation boundaries.

What has that got to do with Enterprise Blockchain and Cyber Security ? Let's find out.

This is a great Enterprise Blockchain story, it's one of my favourites, like the BCP one, it's so easy to implement and so effective and protects Data and Systems and Business Partners across so many dimensions, read on to find out why.

So buckle up and enjoy the ride...

B2B Business Processes, also known as, Multi-Party Collaboration, the following common Business Processes and others can all include elements of 3rd Party Organisation integration:

Order-To-Cash
Procure-To-Pay
Plan-To-Produce/Plan-To-Inventory
Record-To-Report
Source-To-Pay
Idea-To-Offering
Count-To-Reconcile
Forecast-To-Monitor
Inspect-To-Comply
Cradle-To-Grave/Acquire-To-Retire

Where ever you have a Business Process which includes sending your Data to a 3rd Party Organisation, to another Company, your Data is being put at risk. When ever you send or replicate or integrate your Company's Data to another Company your Data is at risk, and this means your Business Process is at risk and therefore your Business is at risk.

This blog is going to be talking about and showing is the weakness of the current approach of working with Data across multiple Organisations which collaborate together on a Business Process.

An easy example is 3PL 3rd Party Logistics.

Your Company needs something delivered and your S/4HANA system sends an instruction to the 3rd Party Logistics company to make a collection and a delivery.

This all looks very normal and very common, but what is actually happening when your Company sends an instruction from the S/4HANA system to the Delivery Planning System at your Partner Company the 3PL 3rd Party Logistics Company ?

Data, it's all about Data, your S/4HANA system is sending Data to your Business Partner the 3rd Party Logistics Company instructing them on where to collect from or deliver to.

And this is the problem, as soon as your Data leaves your network, it's no longer your Data, and you lose control of the Data.

This is a classical Integration scenario, the S/4HANA is Integrated to the 3rd Party Logistics Company's System and you send them your Data. What happens to that Data at your Business Partner is beyond your control, you can only trust that they will care for your Data the same way as they would care for their own Data.

This is how you are doing it today, with IDOCS and API's, this is legacy Data Integration through Replication:

Cyber Security Risk SAP Customers have to share Master Data with Partners Legacy Integration through Data Replication atkrypto.io

This creates several problems including:

Trust between Partners: The more Partners in a Business Transaction or Business Process, the less trust there is between Partners. This is a very simple graph, as the number of Partners in a Business Transaction or Business Process goes up, so the trust between the Partners goes down. What is trust in a Business Transaction or Business Process, doing what you said you would, data, instruction, confirmation. I will deliver the parcel to the address you gave me, but what if somebody in my Team changes the delivery address for their own benefit ?

Protect the Originality & Integrity of the Data - When your S/4HANA sends the Data to your Business Partner's System we need to make sure that the Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data

Replicating & Integrating the Data from your S/4HANA to your Business Partner's System and at the same time Protect the Originality & Integrity of the Data - we need to get the Data from the S/4HANA to the Business Partner's System and we need to be sure, to have surety that the Data which arrives at the Business Partner's System is the same Data as was sent from your S/4HANA. If this Data can be changed in any way, we won't be able to trust the Business Processes and Insights which are depending on that Data. And so, in the activity of moving the Data we need to make sure that that piece of Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data

and it doesn't end there, it's often the case that a 3rd Party Organisation will be getting Data directly from your S/4HANA (as the Source) or posting Data to your S/4HANA (as the Target), in both cases it could be an API which through your Integration Technologies is ultimately exposed to the Internet and where the system calling the API needs to have a User on your S/4HANA.

And 3rd Party Logistics is only the tip of the iceberg when it comes to Multi-Party Collaboration and Business Transactions and Business Processes. You know how integrated your Systems are with your Business Partners how the data is flowing in and out of your network to and from your Partner's networks.

And so, here we are,

The biggest threat to B2B Business Processes is Cyber Security and Cyber Attacks

The biggest threat to Multi-Party Collaboration is Cyber Security and Cyber Attacks

And that's where the Enterprise Blockchain comes in, and this blog is going to explain why.

This blog will be less about deep dives into Use Cases and more about how Enterprise Blockchain is:

. A Secure Store of Data

. A Secure Communication Channel for Data

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth

Subsequent blogs will deep dive individual use case by use case, this one will focus on the principle of Enterprise Blockchain already today being the next generation Secure Store and Secure Communication Channel for Data and how and why.

Ok let's go 🚀

Welcome to the ninth blog in this series on Enterprise Blockchain and SAP. If you have been following the previous blogs then you'll be familiar with the blog template. We'll begin by talking about and framing the problem, in this case Data Cyber Security for B2B Business Processes and then go in to identifying the enabling technology which will have the best capabilities and be the most appropriate to solving the problem all the way through to the reference solution architecture to be able to implement the solution.

The blog is going to break the subject down in to three sections:

Section 1.0: The What is it of B2B Business Processes and SAP, and Enterprise Blockchain

Section 2.0: The Why is it, of B2B Business Processes and SAP, and Enterprise Blockchain

Section 3.0: The How is it, of B2B Business Processes and SAP, and Enterprise Blockchain

In case you missed them, the previous blogs in this series are here:

Why I love SAP and Blockchain Databases and why you should too 🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain🚀

Oil & Gas - Ultimate Data Security - Blockchain Data Backbone from OT to SAP IT🚀

The What Is... The Why To... The How To... of: ESG & SAP & Enterprise Blockchain 🚀

BCP: Business Continuity Planning for SAP S/4HANA - made easy with Enterprise Blockchain 🚀

Trustable AI thanks to - SAP AI Core & SAP HANA Cloud & SAP S/4HANA & Enterprise Blockchain 🚀

IoT - Ultimate Data Cyber Security - with Enterprise Blockchain and SAP BTP 🚀

tl:dr

Enterprise Integrations and Integration Architecture centered around sending and replicating Data to Business Partners results in you losing control of your Data, and losing surety that the Business Partner is looking at the same Data as you are.

The Digital Transformation of Enterprise Integrations is to have a shared common single source of truth for data with your Business Partners.

Enterprise Blockchain is the answer, Enterprise Blockchain enables both Business Partners, you and your Business Partner to share the same Distributed Ledger and consequently have a common shared single source of truth for data across multiple Companies.

That's one thing, the next thing is that thanks to the special characteristics of the Enterprise Blockchain Distributed Ledger, namely, Immutable, Hash Mechanism, Consensus, Distributed, when you or your Business Partner write data to the Enterprise Blockchain, you know, that nobody can modify the Data for their own gains, your know that natively, out of the box you have the highest level of Data Cyber Security and Resilience of any commercial database product available.

In the 3PL scenario, this is what your SAP Technical Architecture would look like:

Enterprise Blockchain as a Shared Common Single Source of Truth for Master and Transactional Data across Organisations with SAP BTP and atkrypto.io

[the finer technical details of the Technical Solution Architecture will be elaborated in the rest of the blog]

The Future of Enterprise Collaboration and Cross Organisation Data Integration and B2B Business Processes (and this is possible today with the SAP BTP and SAP Partner Edge Open EcoSystem Partner Enterprise Blockchain Products).

And as will be explained later in the blog, it's not only about the Enterprise Blockchain being a common shared source of truth across organisations, it's about digitally decoupling the S/4HANA from 3rd Party System Integrations and gradually ring fencing the S/4HANA away from being directly accessed by 3rd Party Systems as it is today with API's.

This is like pick your own strawberries, instead of sending your Partners the strawberries, you tell your Partner the strawberries are ready and which field they are in and you let your Partners pick the strawberries themselves from the Enterprise Blockchain.

S/4HANA Data Events write the Data to the Enterprise Blockchain and S/4HANA Notification Events notify the Partner that something has happened, then, instead of calling an API on your SAP S/4HANA, the Partner then calls the API of the Enterprise Blockchain and Reads the Data from there.

The Enterprise Blockchain Database software is running on your SAP BTP Kyma Runtime and in your Partner's Servers, therefore, creating natively, out of the box, the most secure and resilient common shared single source of truth. Your have a Distributed Ledger running from your SAP BTP to the Partner's Servers.

Enterprise Blockchain Multi Party Business Processes Data Sharing atkrypto.io

Therefore, S/4HANA Data Event Writes to the Enterprise Blockchain as the Common Shared Single Source of Truth across the Organisations, and the S/4HANA Notification Event notifies the Partner that something has happened and that they should call the Enterprise Blockchain API to get the Data of what has happened.

Enterprise Blockchain is:

. a Secure Store

. a Secure Communication Channel

. a Shared Common Single Source of Truth for Master and Transactional Data across Organisations

Enterprise Blockchain is the Cyber Security for Enterprise B2B Business Processes and Multi Party Collaboration.

and now.... the long answer...

Section 1.0: The What is it of B2B Business Processes and SAP, and Enterprise Blockchain

What are B2B Business Processes, what is Multi-Party Collaboration, what are 3rd Party Integrations, what is it all and why do we need it ?

B2B Business Processes, Multi-Party Collaboration, in the context of this subject, these are any Business Process in your Company which includes your Master and Transactional S/4HANA Data being used by another Company, and results in the other Company needing access to your Data.

There are many examples, in today's world of outsourcing that which is not considered part of the core Business, Multi-Party Collaboration is very common across most lines of the Business. Another easy and common one is outsources Payroll.

As described in this blog, by @mert_turan , your Company is using a 3rd Party Payroll provider to take care of your Payroll, the process and the integration can look like this:

Payroll Process by Mert Turan

This is a classic example of a B2B Business Process, where your Company is sending highly sensitive and highly confidential Data, transferring that Data to a 3rd Party Company, in this case a 3rd Party Payroll Provider. Look at all of the Data transfers which are going on in that Payroll Business Process.

Just look at the sensitivity and confidentiality of the Data which is being transferred to the 3rd Party Company, Personal and Business Sensitive Master and Transactional Data.

What could possibly go wrong ?

What could possibly go wrong with any of these Multi-Party Collaborative Business Processes, Payroll, Supplier Network Collaboration, 3rd Party Logistics, Contract Manufacturing ?

What is the biggest risk ?

The Data, again, it's all about the Data, and keeping the Data safe, and reducing the chance that somebody can mess with the Data.

What about the Enterprise Blockchain, what is Enterprise Blockchain ?

Enterprise Blockchain is both:

. a Secure Store

. a Secure Communication Channel

In these previous blogs, I made a deep dive in to what Enterprise Blockchain is and why we should be positioning it in our Enterprise Architecture:

Why I love SAP and Blockchain Databases and why you should too🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain 🚀

Enterprise Blockchain Multi Party Business Processes Data Sharing atkrypto.io

and in a nutshell, Enterprise Blockchain is:

. The Digital Transformation of Information Security into Cyber Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

To wrap up this section:

. B2B Business Processes are about Data

. Enterprise Blockchain is about Cyber Security of Data

Section 2.0: The Why is it, of B2B Business Processes and SAP, and Enterprise Blockchain

So, why B2B Business Processes in the Enterprise IT, when implemented in conjunction with SAP Applications need Enterprise Blockchain ?

Multi-Party Collaboration is about replicating Data to 3rd Party Company, and the Data, this is your Company's Data and in most cases highly sensitive and highly business and personally confidential.

The problem is the Cyber Security of getting the Data from the your Company's SAP S/4HANA to the 3rd Party Company's Application, and ensuring the originality and integrity of the highly sensitive and confidential Master and Transactional Data which you are replicating to the Partner Company remains intact.

As we talked about earlier, and this is worth repeating because this is the problem of Multi-Party Collaboration:

ITSecurityWire.com, in their article, Best Practices to Secure Data Integration, put it like this:

The LinkedIn Community describe the risks of Data integration like this:

Those are the problems with today's legacy ways of making your S/4HANA Master and Transaction Data available for 3rd Party Companies in your B2B Business Processes.

And what's the solution ?

The solution is the Enterprise Blockchain as the Common Data Back Bone across Companies.

Instead of replicating and sending the Data to your Business Partner, you write the S/4HANA Data to the Enterprise Blockchain.

Imagine, as described in the previous blog, when we let the Use Case find the Enterprise Blockchain, we have a Business Requirement, a Business Demand, to make Data for B2B Business Process the safest it can be, the most trustable that it can be.

Comparison Enterprise Blockchain Database and Traditional Legacy Database - atkrypto.io

B2B Business Processes are about Data

B2B Business Processes are about the Data that goes from your S/4HANA outside the boundaries of your Company and your Network and to Partner Company's Applications and Networks and Databases.

This means B2B Business Processes are about Data and the Data depends on a Database or a Datastore

What kind of Database do B2B Business Processes Data need ? What capabilities does the Database for the B2B Business Processes Data need to have ?

1. It must not be possible to modify the Data in the Database ]- the Database needs to be immutable

2. The Data in the Database, the integrity and originality of that Data must be protected to the highest level that is technically possible

3. The Data must be available with the highest availability, the Database must be resilient to attack

4. The Database must be running simutaneously in your DataCenter and your Business Partner's DataCenter

5. S/4HANA must not expose any API's to Business Partner Companies

When we look in our Enterprise Technology Standards we find 1 Technology Standard in the Enterprise which has those capabilities, and that is..... Enterprise Blockchain

Enterprise Blockchain ticks those boxes...

Immutable - tick that box

Integrity must be protected to the highest level - tick that box, thanks to the Enterprise Blockchain Hash Mechanism and the Enterprise Blockchain Consensus Mechanism

Highest level of resilience and availability - tick that box thanks to the Distributed and Decentralised nature of the Enterprise Blockchain

DeCouples S/4HANA from the process, no need to S/4HANA API's to be exposed to 3rd Party Business Partner's Applications

This is why, Enterprise Blockchain is the enabler of trustable outcomes from Enterprise B2B Business Processes.

atkrypto.io what is a blockchain

But there's more than that, B2B Business Processes can produce a lot of data, and the volumes of data can be big.

And this is why, in this blog we take the Enterprise Blockchain Technology story one level further and we introduce the:

Enterprise Blockchain Wallet

Off-Chain Data Storage

In the Enterprise Blockchain Platforms, the Enterprise Blockchain Wallet is used for Off-Chain storage of big data and in the following paragraphs we will explain why.

What is the Enterprise Blockchain Wallet, and what is Off-Chain Data Storage and why would we use them and why do we need them ?

Blockchain is a very simple form of database atkrypto.io

But, Payroll can produce a lot of Data, and in large volumes which would be too big to be stored on the Enterprise Blockchain Database itself.

So, if we can't store the large photographs files in large quantities to the Enterprise Blockchain Database, then how, in an Enterprise Blockchain Platform do we store large files of Data ?

The Enterprise Blockchain Wallet enables us to store large Data, like large Files safely and securely off the chain, or 'Off-Chain'.

But if we store the large Data files Off-Chain in the Enterprise Blockchain Wallet, then how do we also have them some how on the Enterprise Blockchain Database ?

The configurable Enterprise Blockchain Wallet of the Enterprise Blockchain Platform looks like this:

Enterprise Blockchain Platform - Enterprise Blockchain Wallets - Configurable Enterprise Wallets - atkrypto.io

Ok, so we've got the large volumes of Data stored in the (configurable) Enterprise Blockchain Wallet, but what about securing the Data ? Obviously the Enterprise Blockchain Wallet storage location has built in security, for example the SAP HANA Cloud, the AWS S3 Buckets, but we need more than the out of the box security of these products, the reason we are using the Enterprise Blockchain Database is because of the amazing security strengths that it natively out of the box has, and so, what about the Enterprise Blockchain Wallet, doesn't the Enterprise Blockchain Platform have some cool super hard way of protecting the data in the Enterprise Blockchain Wallet ?

Well yes it does, this is the magic of Enterprise Blockchain Database 'Off-Chain' storage in the Enterprise Blockchain Wallet. This is so unique to Blockchain Technologies.

The data or the file in the Enterprise Blockchain Wallet gets hashed, and then, that hash is stored in the Enterprise Blockchain Database.

Enterprise Blockchain Wallet Data Hashes Stored in the Enterprise Blockchain Database - atkrypto.io

And this is why, for all of these reasons,

Trustable Enterprise B2B Business Processes depends on Data being stored in the Enterprise Blockchain

But that's not the end of the b2B Business Processes need Enterprise Blockchain.

As we showed at the beginning of the blog in this picture:

Enterprise Blockchain Multi Party Business Processes Data Sharing atkrypto.io

As the picture shows, we have an Enterprise Blockchain Database Tenant installed on a Server Host at the in your DataCenter, in your Network on your SAP BTP Kyma Service AND we have an Enterprise Blockchain Database Tenant installed on your B2B Business Partner's Network, if they are a SAP Customer then like you they can put it on the SAP BTP Kyma Service, if not they can run it on Kubernetes.

The consequence of this is that we have a distributed Enterprise Blockchain Database table which stretches from your DataCenter and Network where your S/4HANA is writing Data to it and stretches all the way across the Network to your Business Partner's DataCenter.

This means we have Enterprise Blockchain Data Protection from the source from your S/4HANA to the target your B2B Business Partner's It infrastructure enabling the trusted resilient reliable Business Processes to be completed.

At the same time, we are not exposing S/4HANA or the API's on the S/4HANA to any 3rd Party Applications.

We have digitally decoupled the S/4HANA from the Business Process.

Enterprise Blockchain as a Shared Common Single Source of Truth for Master and Transactional Data across Organisations with SAP BTP and atkrypto.io

To conclude this section, the Why to, B2B Business Processes and Enterprise Blockchain, B2B Business Process Data needs to safely replicated and trustable.

Enterprise Blockchain, due to its native super strong security strength when used as a store of Data enables B2B Business Processes to be both Secure, and Trustable.

And as we will see in the next section, it's not only about the Enterprise Blockchain being a common shared source of truth across Organisations, it's about digitally decoupling the S/4HANA from 3rd Party System Integrations and gradually ring fencing the S/4HANA away from being directly accessed by 3rd Party Systems as it is today with API's.

Section 3.0: The How is it, of B2B Business Processes and SAP, and Enterprise Blockchain

The goal of this blog was to show how instead of using the legacy fire and forget approach of replicating data to 3rd Party Business Partners, the Enterprise Blockchain can be deployed as a common shared single source of truth running, with an Enterprise Blockchain Tenant running close to your S/4HANA and another Enterprise Blockchain Tenant running close to your Business Partner's Application.

In this section of the blog we will show all of the possible potential Technical Solution Architectures which will enable you to implement this next generation approach to sharing Data with the highest level of Cyber Security already today.

As described above one of the many beauties of this approach is your S/4HANA writes to the Enterprise Blockchain and your Business Partner's Application reads from the same Enterprise Blockchain. This achieves a number of things including:

. Total Control - you have total control over the Data you are sharing with the Business Partner, and you know that as long as your Business Partner's Application reads the Data from the common shared source, the Enterprise Blockchain

. Ultimate Cyber Security - then you know the maximum has been done to minimise the chance for Cyber Security risks and the maximum has been done to protect originality, integrity, and confidentiality of the Data

. S/4HANA Digitally DeCoupled from the Business Process - and on top of this, the S/4HANA has been digitally disconnected from the Business Process, because no longer do any 3rd Party Applications directly call API's on the S/4HANA

In the Technical Solution Archecture there would be two main ways for getting the data from the S/4HANA and writing it to the Enterprise Blockchain, these would be:

. API's

. Events

In these Technical Solution Architecture examples we will prioritise using S/4HANA Events to write the Data to the Enterprise Blockchain, we will be sending the Event Notification and the Event Payload, we could of course draw the same Technical Solution Architecture with API's, but we prefer the Events for the simplicity and reduced call backs to the S/4HANA and therefore making the S/4HANA more Digitally DeCoupled and therefore, enabling the S/4HANA to be protected to the higher security level and exposed to less Cyber Security risk.

Ok, let's go with the Technical Solution Architectures, in these examples we will focus on the OutSourced Payroll as the integration and B2B Business Process Example.

What do we have and what do we need:

Your Company will need:

. S/4HANA

. SAP EM and preferably SAP AEM since it has richer Security and Event Payload size capabilities and can Publish Events from Non-SAP Enterprise Applications and connect to your Enterprise Event Mesh

. SAP BTP

. SAP BTP Kyma Runtime Service - this is where the Enterprise Blockchain Container will run

. Enterprise Blockchain Platform Software which can run on Kubernetes

. If there will be larger Data objects then you will need Large Storage for Large Data and the Enterprise Blockchain Wallet in the form of SAP HANA Cloud (Data Lake)

Your Business Partner will need:

. Obviously their Payroll Application

. Either SAP BTP with Kyma Runtime, or Servers which can run Kubernetes Containers

. n.b. there is an Optional Technical Solution Architecture where you simply allow your Business Partner to read data from your Enterprise Blockchain where the Enterprise Blockchain Platform is running exclusively on your BTP, we will show that Option as well

Technical Reference Solution Architecture for SAP S/4HANA and SAP SuccessFactors and OutSourced 3rd Party Payroll Provider using Enterprise Blockchain as a Common Shared Single Source of Truth for Data and the Ultimate Cyber Data Security for B2B Business Processes...

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to Enterprise Blockchain atkrypto.io

In the next example, we have the same basic Technical Solution Architecture as the previous example, except, this Reference Use Case is ready for the Enterprise Blockchain needed to be able to handle large volumes of data and brings the Enterprise Wallet in to the picture. In the Enterprise Blockchain Platform the Enterprise Wallet storage is configurable and therefore could be SAP HANA Cloud (DataLake) or AWS S3 Buckets or other HyperScaler Data stores.

All of the other Cyber Security characteristics remain the same, S/4 is digitally decoupled from the Business Partner, Enterprise Blockchain is used as a common shared single source of truth for Master and Transactional Data, and the Enterprise Blockchain Tenants are running in both your DataCenter (AnyPremise) and the Business Partner's DataCenter (AnyPremise):

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to Enterprise Blockchain & Enterprise Wallet atkrypto.io

The next example Reference Technical Solution Architecture is a little bit different, let's assume, for their own reasons, your Business Partner is not going to run an Enterprise Blockchain Tenant in their (AnyPremise) DataCenter.

This is still fine, you will set up the Enterprise Blockchain Platform in your DataCenter(s) (AnyPremise) and your B2B Business Partner, in this case the outsourced 3rd Party Payroll Vendor will simply use API's to read and write to and from your Enterprise Blockchain.

All of the other benefits of the design remain the same, all of the other next generation Data sharing Cyber Security characteristics are still there, S/4 is digitally decoupled from the Business Partner, Enterprise Blockchain is used as a common shared single source of truth for Master and Transactional Data.

Here it is:

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to your Enterprise Blockchain atkrypto.io

Finally, we have the same Reference Technical Architecture as above, but to be able to cater for large volumes of Data we include the Enterprise Wallet in the design:

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to Enterprise your Blockchain & Enterprise Wallet atkrypto.io

Ok let's wrap this up, the conclusions:

Ultimate Cyber Security for B2B Business Processes is Enterprise Blockchain, where the Enterprise Blockchain acts a common shared single source of truth for Data across Organisations

Enterprise Blockchain is:

. A Secure Store of Data

. A Secure Communication Channel for Data

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth

The next generation Integrations don't replicate Data, that's legacy, the next generation Integrations use Enterprise Blockchain as a common shared single source of truth.

The configurable Enterprise Blockchain Wallet enables you to store Big Data 'Off-Chain' and the hashes of the Data are stored safely and securely on the Enterprise Blockchain Database.

So what are we waiting for ? Oh yeah, deep dive in to more use cases, ok, that will be the next blog.

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

All of this makes atkrypto,io the DePIN Decentralised Physical Infrastructure Network solution for Enterprise.

atkrypto is one of the Next20 startups being featured at TM Forum's DTW Ignite in Copenhagen in June

If you will be at DTW24 come and talk to us about Cyber Security of SAP Data with Enterprise Blockchain.

RingFencing & DeCoupling S/4HANA with Enterprise Blockchain and SAP BTP - Ultimate Cyber Security 🚀

2024-05-14T13:56:58.227000+02:00

tl;dr

As part of S/4HANA Transformation Programs, Security, Accessibility, Resilience are being re-imagined.

The going in position for a lot of S/4HANA Transformation Programs includes the Cyber Security principles:

Only Employees will have direct access to the Digital Core as End Users
There will be no direct access to the Digital Core by 3rd Party Applications

The first principle, 'Only Employees will have direct access to the Digital Core as Users', decoupling the SAP system for External Users has been an architectural design pattern for more than a decade. For example, due to the extremely sensitive and confidential nature of Product LifeCycle Management Data, 13 years ago SAP were advocating, building an empty SAP PLM system in the DMZ which would use RFC's to communicate with the actual SAP PLM system in the Secure Network Zone:

The beauty of this design is that it decouples End User Access from the core SAP PLM system, therefore enhancing the security protection of the SAP PLM system.

Today's equivalent of that is to put the SAP Build Work Zone Launchpad in front of the S/4HANA Digital Core.

That is fine, that means the Digital Core is digitally decoupled for End Users, but what about Machine to Machine, Application to Application, 3rd Party Applications which want to get Data from the S/4HANA ?

Do you really want 3rd Party Companies calling APIs on your Digital Core - atkrypto.io

When a 3rd Party Company calls an API on your S/4HANA Digital Core, you are replicating your Data to that 3rd Party Company.

How can the S/4HANA Digital Core be decoupled when 3rd Party Applications need to get Data from the S/4HANA, how can the S/4HANA Digital Core be architected in such a way that there are no Machine to Machine calls directly to the S/4HANA for the purpose of getting Data ?

As elaborated in more detail in a previous blog, API's enable your Data to be replicated to 3rd Party Applications which can also be in 3rd Party Partner Companies, and this brings a set of problems centered around:

As ever, the pattern is the same, the theme is the same,

it's all about the Data

what are the security, sensitivity, confidentiality, availability, criticality requirements of the Data

Ring Fencing S/4HANA raises the Cyber Security by reducing the attack surface.

The most secure way is with Enterprise Blockchain as a Data Ring Fence around the S/4HANA Digital Core, therefore digitally decoupling access and integration of the S/4HANA Data from other Applications.

The Enterprise Blockchain is:

. Ring Fencing of the S/4HANA

. S/4HANA does not expose API's directly to any 3rd Party Companies

. A Secure Store of Data

. A Secure Communication Channel for Data

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth

The S/4HANA Ring Fencing with Enterprise Blockchain as a shared single source of truth could involve the Enterprise Blockchain running on your SAP BTP Kyma Runtime and at the same time running on Kubernetes Servers in your Business Partner's Data Center:

S4HANA RingFenced by Enterprise Blockchain S4HANA does not expose any APIs directly to 3rd Party Companies Ultimate Cyber Security - atkrypto.io

Or alternatively the S/4HANA Ring Fencing with Enterprise Blockchain could be where the Enterprise Blockchain is running on your SAP BTP Kyma Runtime and your 3rd Party Business Partner Company reads the Data from your Enterprise Blockchain on your SAP BTP Kyma Runtime as a shared common single source of truth for the Data:

S4HANA RingFenced by your own Enterprise Blockchain S4HANA does not expose any APIs directly to 3rd Party Companies Ultimate Cyber Security - atkrypto.io

Read on for the full story... 🚀

Introduction

The reason I am so interested in this is I have been securing availability and accessibility of SAP systems for the last 25 years, and back in 2013 I wrote this blog about "Alternatives for Securing Internet Facing Applications".

There is so much to talk about on this subject, let's get in to it. Back in 2013 at a Customer, we were looking at Ring Fencing critical systems.

Back then the focus was on DeCoupling the SAP system where End User access was required from people coming in from the Internet, infact the reasons for the RingFencing were centered around:

Access - Authentication & Authorisation
Storage of Data
Communication Channels
DeCoupling especially for Internet Collaboration

The DeCoupling for Internet Collaboration was based around SAP's SAP PLM Reference Architecture,

and the SAP PLM Technical System Landscape recommendation:

Fast forward to today, and SAP Customers have the luxury that the worry of securing End User Internet Access to their SAP systems is outsourced to SAP through the implementation of the SAP BTP Build Work Zone Launchpad. It should not go unnoticed that when you implement the SAP BTP Build Work Zone Launchpad Service, you also don't have to care for Web Access Firewalls and the Security of Internet Access.

But what about API's, what about System to System, Machine to Machine ? What about Integrations ? What about when Non-SAP Applications in your Company or other Companies need data from the S/4HANA ?

S/4HANA has a rich collection of API's which is always growing, but, should Applications from your Partner Companies call API end points on the S/4HANA Digital Core ?

Should 3rd Party Applications, and 3rd Party Partner's Applications be directly accessing the Digital Core S/4HANA API's ?

Regardless of whether the S/4HANA is an [Any]OnPremise, S/4HANA RISE Private Cloud Edition, S/4HANA Public Cloud Edition, should 3rd Party Applications be allowed to directly call API's on your S/4HANA ?

Let's take the S/4HANA Business Partner API, should Applications from your Partner Companies be allowed/able to call this API on your Digital Core S/4HANA to retrieve changes to Business Partner Data ?

Legacy API Integrations calling S4HANA API and Replicating Data to 3rd Party Company Applications - atkrypto.io

If you have doubts or think the answer is no, then read on, there is a solution, it is very nice, and very easy, and very secure.

One of the biggest Cyber Security threats to your Data and therefore your Operations and therefore your Business, is allowing 3rd Party Applications from 3rd Party Companies to call Data from API's on your S/4HANA Digital Core, and then, replicate your Data to Servers in their Company.

As ever, the pattern is the same, the theme is the same,

it's all about the Data

what are the security, sensitivity, confidentiality, availability, criticality requirements of the Data

Like the other blogs in this series, this blog is going to break the subject down in to three sections:

Section 1.0: The What is it of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

Section 2.0: The Why is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

Section 3.0: The How is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

In case you missed them, the previous blogs in this series are here:

Why I love SAP and Blockchain Databases and why you should too 🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain 🚀

Oil & Gas - Ultimate Data Security - Blockchain Data Backbone from OT to SAP IT 🚀

The What Is... The Why To... The How To... of: ESG & SAP & Enterprise Blockchain 🚀

BCP: Business Continuity Planning for SAP S/4HANA - made easy with Enterprise Blockchain 🚀

Trustable AI thanks to - SAP AI Core & SAP HANA Cloud & SAP S/4HANA & Enterprise Blockchain 🚀

IoT - Ultimate Data Cyber Security - with Enterprise Blockchain and SAP BTP 🚀

B2B Business Processes - Ultimate Cyber Data Security - with Blockchain and SAP BTP 🚀

Section 1.0: The What is it of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

What is RingFencing ? There is a very nice description here:

RingFencing is about isolating Data, away from the most important SAP system, the S/4HANA Digital Core.

DeCoupling, the word DeCoupling has a number of meanings in Enterprise IT. What we are talking about here in the case of the S/4HANA Digital Core and Data access by 3rd Party Company Applications is that we are DeCoupling the Data access away from directly on the S/4HANA, by DeCoupling we are making the S/4HANA Data indirectly accessible.

It can be thought that if we are RingFencing, or Isolating, or DeCoupling the S/4HANA Data away from the S/4HANA then we are creating another copy of the Data, another Replica of the Data, which is true, we are, and that is the same as when Data is replicated to 3rd Party Systems via API, whichever way you look at it, the ultimate goal is a Replica of the S/4HANA Data which is available and accessible to the 3rd Party Company Application for the reasons of that Application of Business Transaction.

We can replicate the Data using an S/4HANA API to the 3rd Party Company Application and lose all control of the Data and also have to deal with how to secure Authentication and Authorisation and Network Access to the API, or we can replicate to our own RingFenced isolated trusted location.

SAP S4HANA RingFenced DeCoupled Data Cyber Security Principles - atkrypto.io

What about the Enterprise Blockchain, what is Enterprise Blockchain ?

Enterprise Blockchain is:

. a Secure Store

. a Secure Communication Channel

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth

In these previous blogs, I made a deep dive in to what Enterprise Blockchain is and why we should be positioning it in our Enterprise Architecture:

Why I love SAP and Blockchain Databases and why you should too 🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain 🚀

S4HANA RingFenced by Enterprise Blockchain S4HANA does not expose any APIs directly to 3rd Party Companies Ultimate Cyber Security - atkrypto.io

and in a nutshell, Enterprise Blockchain is:

. The Digital Transformation of Information Security into Cyber Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

To wrap up this section:

. RingFencing is about isolating and protecting Data

. Enterprise Blockchain is about Cyber Security of Data

Section 2.0: The Why is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

Why would we want to RingFence and DeCouple S/4HANA, the Digital Core from 3rd Party systems which legitimately need S/4HANA Data ?

The answer is simple, Cyber Security, Cyber Threats.

Not so long ago, the focus was on High Availability and Disaster Recovery, the biggest threat was the system going down and not coming back.

Today, things have changed, and the biggest threat is a malicious actor rendering our business Data unusable.

Today we know we can buy new servers, we know we can get a Data Center up and running, but how do we repair Data which has been maliciously rendered unusable ? Think about the Ransomware attack.

So what is ring fencing and why do we need to do it ?

Ring Fencing is about reducing exposure to Cyber Threats.

What are the biggest easiest ways that we can reduce exposure to Cyber Threat ?

Stop 3rd Party Companies from calling API's on the S/4HANA Digital Core.

Stop publishing API's for 3rd Party Application access on the S/4HANA Digital Core.

Stop doing this: