Challenges of applying Agile in building SAP cybersecurity software
In this blog, we do something different. We focus on how a modern software company designs cybersecurity. Specifically, we refer to how the application of methodologies like Agile can actually be a source of risk for customers.
You can say that the whole idea behind Cybersecurity is that not everyone has access to everything. There are many ways to do it in SAP, but perhaps the official way to access everything (or almost everything) is via SAP_ALL. This well-known permission makes users feel like Super Mario after eating the start power-up. You will probably find the control of SAP_ALL assignment in any vulnerability management (VM) solution on the market, and that´s correct because it´s something to be worried about.
The only problem is that a typical VM scan is not programmed to run hourly. But even so, an “attacker” would still have 50 minutes to do something inappropriate, which is a lot. This kind of issue brings Threat Detection tools to the market, a permanent monitoring tool that reacts immediately when this kind of event is detected. You will probably also find the detection of a user operating with SAP_ALL in any Threat Detection tool.
Suppose then we are now members of a modern software company:
As most software companies, we build products using Agile. We move fast and involve our customers in our design. We don´t focus like in the past on infinite documentation or architecture because we know that the person who knows the business process is the end-user. (S)he is the person who tells us if what we produce fits or not with the business needs. Our design originates from customer interaction in many channels, pre-sales, marketing, or Customer Success Management. We are proud and happy to keep this relationship with our customers.
So, let´s see how Agile helps us to create our first control to detect users with SAP_ALL.
If we talk about design, our Product Owner (PO) is the core of our product. He is not only responsible for the definition and prioritization of backlogs. He interprets and translates customer needs into technical specifications, so the development team can run the “Scrum Machine” and produce quickly, to let the user validate our products’ efficiency. Our PO sometimes interacts with the customer, but he typically receives requirements from our Product Managers or our Business Owners.
When our PO received the request to “detect users with SAP_ALL”, we quickly evaluated a scan method that controls every minute the logged users in the system. With the permanent picture of the users, he quickly extracts their permissions and evaluates if SAP_ALL is assigned. Once this is detected, the solution immediately sends you an alarm to our Dashboard and an urgent email to the security team.
After a few days, our customers raised a new requirement: Include a whitelist to stop the spamming of alerts from all the technical users that, in the background, were detected using SAP_ALL. And yes, we know it´s wrong, but according to our customer’s security maturity level, they still accept even some dialogue users with an SAP_ALL.
Again, our PM, who rarely sleeps, immediately sent the requirement to our PO, and both, together with the scrum master, started the implementation. The sprint ran, and we successfully delivered in a record time.
This is how we work with Agile. Far away from the old days when we used to have more documents to read than lines to code. Sometimes I miss those days.
Sometimes I drink a coffee with our PO, and chat about how, since we work with Agile, we move that fast and efficiently to make the stakeholders happy that with the rush, we lost this space to fully explore different design options before beginning development. How the breaking down works into sprints, sometimes we don´t have time to iterate on design alternatives as much as we want. We deliver software quickly and efficiently, but the market demand primarily predetermines it. But it´s okay. Our MVP prioritizes the functionality customers want, and customers know what they need.
Unfortunately, the lines above describe precisely how many software providers build their products, and unfortunately, this is a real example of an SAP_ALL threat detection control. This Agile success story in Cybersecurity, it´s at the same time, the consolidation of a relatively stable new attack surface.
It’s not about whether Agile is a good or bad methodology, but rather the challenges of applying it to highly specialized products where there is no external organization to validate them, and it’s not possible to assume that the client can do so.
In our next blog, we will explain why in Protect4S we think and act differently. We will explain in detail how we developed this control and share some risks derived from the methodology used. We’ll give some pointers on where to be careful to take advantage of Agile benefits in cybersecurity development.
Interested to learn more? Want a demo? Or start a free Proof of Concept? We are happy to tell you more about our SAP Vulnerability Management and SAP Threat Detection capabilities. For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn!
