The critical value of the Design and Research in SAP Cybersecurity
In the previous post, we presented a success story of using Agile methodology in implementing a user control with SAP_ALL in an SAP cybersecurity solution. In this post, we will expose some questions and reasons on how this methodology can affect the quality and the security of companies.
It is undoubtedly vital to detect the use of SAP_ALL in an SAP production system. Yes, it is a bad practice that needs to be controlled. But the first thing to understand is that whoever has access to manipulate a user’s attributes can also change their password. Also, the assignment is not the event to control but the user login action. The expected scenario is not that a user assigns an SAP_ALL, but the attacker impersonates an identity with SAP_ALL, starting with users on the whitelist: the perfect attack surface. An exceptions list must be more exhaustive than just the user’s name. We must ensure that known and accepted users operate from known and accepted terminals. Otherwise, it is perfectly inferable that there is a user impersonation, which is the effect of an attack for this type of risk. An exception table is needed, but the host must be added. This way, we arrive at the synthesis step: the control of SAP_ALL must be controlled recursively by evaluating the longing. If user and host, are not authorized on the whitelist, the event should be considered a threat.
At this point, the design can be stopped. A series of improvements have made the check reach the level of threat detection. The reader who is less familiar with the area may think that this is just an improvement of the implementation of the previous post, nothing more. However, the reader, who is more familiar with security, will see that from now on, the check goes from a mere tool for detecting bad practices between users and administrators to a cybersecurity tool. At this point, an MVP can be considered valid so that this control becomes a proper threat control. Knowing when to stop investigating to produce a consistent product is a pure exercise of product design. And this can never be carried out by the product manager or even less by the end user. Design, especially in cybersecurity, is the exclusive domain of the expert.
Design is a continuous process of observation and synthesis, an empathy exercise. It is never truly complete. A skilled designer understands this. Design is an individual exercise. Observation and synthesis are psychological and personal phenomena, not collective actions. Sometimes, those who blindly champion teamwork view this fact as hostile. Of course, a collective dimension is necessary. Only in teams we can consolidate and plan projects. But the analytical process is intimate and reflective. Think of the Beatniks or the people of Paris of Montparnasse. The work of Barragán looked nothing like the work of Kahn, and it was Barragán who advised Kahn in the development of Salk Institute, perhaps his masterpiece.
On the contrary, in Scrum or Design Thinking, it is challenging to find differences regardless of the region where they are practiced. The same language, behavior, the way of expressing themselves. The reason is simple: in Agile or Design Thinking, the creative and analytical dimensions are reduced to a minimum. The hours of productive silence seem to have no place in Agile. Construction is the absolute tyrant.
In software development, Agile is undoubtedly efficient. Products can be created even without extensive knowledge in the area. Its effectiveness is more than proven, but Agile doesn’t move that fast without sacrificing something. Agile delegates the design and testing exercises to the end-user, assuming they know their activity and business process better than anyone else. No one else can better assess the effectiveness of a product in improving their business processes than the end-user. With this strategy, software companies transfer a significant part of the design, including testing, to the end user. Documentation and design periods are reduced to the minimum viable product (MVP), and teams can simply focus on production. However, they slowly lose ownership of what they produce. Implementing the solution that another has found, implementing the PM or Business Owner requirement, is not a design action; it is simply implementing someone else’s design. And this is perfectly acceptable as long as the end-user is the expert, which is rarely the case in cybersecurity. Even more, cybersecurity does not aim to improve existing business processes, it aspires to protect them, inaugurating or expanding new security practices.
Cybersecurity products are highly complex entities resulting from meticulous individual research. It is illogical to assume that the end user will be the expert who validates their efficiency. It is possible to obtain benefits from Agile, without a doubt. But neither the design nor the research should be sacrificed. A company that adopts Agile in developing cybersecurity tools must know how to protect and shield its design team. Agile should be an instrument of the researchers, not the other way around. The impetus of development should never force research to compromise its standards. This misstep can lead us to the worst of risks: to believe that we are controlling something when, in reality, we are creating silenced attack surfaces…. Many years ago, I had a friend who had a friend who used to look at the user whitelists for SAP_ALL controls… and he used to always finish the work before us.”
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!
