I believe that every customer has the possibility to configure their entire landscape securely with the best available technology. It disturbs me when customers tell me that they did not know about specific security products or features. I have received this feedback a lot lately. I want to change this and I will use the example of my very first customer, because it offers a holistic security overview and a great learning experience.
Where do you start when you want to secure your IT landscape? Of course you have to do the usual and set up and configure firewalls, network and endpoint security, encryption of communication paths, anything related to perimeter security. However, this is not enough.
I suggest that we start from the bottom – up or the inside – out, if you will, and begin as close to the sensitive assets as possible. Gartner has an interesting view on this. According to some of their research about Runtime Application Self Protecting (RASP) they come to the conclusion: “Stop Protecting your Apps, It’s Time for Apps to protect themselves”. Gartner explains that solid security self-diagnostics and self-protection is key. What gets exploited? Well it is always data and applications. So where do we have to look then? We have to check the code.
When I started at SAP, I started in HR Consulting. However, my first customer (they were implementing the HR product), was worried about their authorization concept. They wanted me specifically to check their custom code, namely their many custom reports, their purpose and whether they had authorization checks implemented. It is a very good practice to have a 4-eye principle when writing custom code. All big software vendors have a secure development life cycle. But, if you can implement an automated tool that checks your code for security vulnerabilities like SQL injection, Buffer Overflows, Cross Site Scripting and missing authorization checks or hardcoded users with passwords, which happens more often than one would believe, you can make your life a lot easier. Be prepared for a large amount of false positives when first using a security analyzer. After you take the initial hurdle you should stay on top of things and check every new code for vulnerabilities on a regular basis.
In the above mentioned consulting project I also set up the requested authorization concept. For that you have to look at users and which roles/authorizations they need. Back then, this was done via a huge spread sheet and questioning the key users for what they do on a regular basis. Today there are tools out there that help identify segregation of duties (SoD) issues via pre-defined sets of sensitive authorizations so that no user aggregates too many rights and privileges. An authorization concept also has to cover topics like unique user names, or how to cleanse current user names, password rules that you want to enforce etc.
So what is next?
The next issue I had to look into at my first customer was a suspicious IT administrator. He had deleted configuration tables 3 times by mistake, but the customer believed that there was more going on behind the scenes (How often do you delete the same table by mistake???). What did I do? I learned about auditing, logging and monitoring. Almost every platform comes with integrated auditing, logging and monitoring capabilities. Some applications, usually business critical applications with sensitive data like HR, FI, CO offer specific table logging to be activated. However, you have to interview key users from the application here, to find out which data is considered especially sensitive for a company. Also search for auditing that specifically relates to security, e.g. logs that identify changes in the user administration esp assignment of vast rights and privileges, users that debugged in a productive system (who has debugging rights and why in a productive system?) etc. Coming back to the example: What had the IT administrator at my first customer done? This IT administrator had created a custom report in the development system and executed it via a remote function call in the productive system. His report extracted the employees and salary information. He tried to delete his tracks, but he deleted the wrong table. Make a mental note here, that remote function calls are critical, esp those that were executed remotely in a productive system, and analyze log data for them! The example should make it crystal clear that perimeter security is not sufficient. To just set up firewalls and network security did not stop this insider at my first customer from performing malicious acts. In addition you can ponder the idea of implementing a Security Incident and Event Monitoring (SIEM) product that will automate the monitoring process and generate alerts. Whether you use a tool or the inherent platform capabilities to implement auditing, logging and monitoring, be prepared to accompany the set up and usage of these technologies via personal support or specific IT crisis management consulting. Why am I suggesting this? Just imagine, that you have given the task of implementing a proper Security Auditing to a Security Expert in your team. She or he successfully implements and configures security auditing and is now confronted with many alerts. What is she or he supposed to do, when they find someone debugging in a productive system? What is the process anyway, when they find that your IT landscape was attacked? There is so much to write on this topic alone, that would be for another blog, but make sure that you create and keep a logbook, while you deem yourself under attack and request a regular (at least daily) situational analysis. And lastly, what does receiving an alert mean for the reputation of this Security Expert? Your Security Experts might come to the conclusion that an alert means that she or he has not done her job properly before the Security Auditing was implemented! They might think that their reputation is at stake, because alerts are popping up, because they did not configure the security correctly beforehand! So you definitely have to accompany this process with change management and set expectations.
What now?
The project at my first customer started small, but got bigger quickly. Initially we had a three-tier landscape with Development, Quality and Productive client and 30 users. But soon after go live we expanded the amount of clients (Test, Sandbox etc) and the number of users. This brought the problem of user administration and data consistency. So I configured an Identity Management and Administration capability available at the customer. This reduced administrative efforts significantly and kept data consistent, which influences security as well. So you want to explore Identity, Governance and Administration products. These usually combine the task to centrally administrate identities and govern SoD issues.
What comes next?
Well, all the users did not want to remember the many passwords to all of the systems. That’s in fact one of the most often uttered complaints that I hear from customers. They don’t like to remember passwords especially when an absolutely necessary password rule enforces a change every so often. Besides setting up a help desk to reset passwords is costly and time-consuming. So you need to configure Single Sign-On and have to check which authentication mechanisms are available and which products will issue corresponding tokens. Usually there is quite a difference between authentication mechanisms in the web (SAML, Oauth, X.509 certificates or SPNEGO Kerberos are the most common implemented mechanisms) or what is available for fat clients and legacy systems. You have to check if you can implement one central authentication and Single Sign-On tool to cover all your systems in your landscape. However, as stated above this might be tricky, since very old legacy applications usually do not support modern authentication tokens. Some customers ask for Enterprise Single Sign-On (ESSO), which is a technology that helps in this situation. The user and password get recorded at first logon and then resend to the application at every subsequent logon. I would recommend that you only implement ESSO, when you really have to and try to stick to modern authentication mechanisms. Another problem to check for is whether you need to implement cross-domain Single Sign-On, e.g. inter-company SSO between you and a business partner. Although many SSO technologies claim that they support cross-domain SSO (SAML does it very well), it can be burdensome and tricky to implement.
Let me summarize my recommendations on how you can secure your landscapes:
You start from the inside out, as if you were getting dressed and you put on one layer after another layer of clothes. You start as close to the sensitive assets as possible. You go in steps:
- Secure your code -> Check for Security Vulnerabilities in your custom code
- Secure your users -> Set up a proper authorization concept including user management and Segregation of Duties checks
- Activate Auditing, Logging and Monitoring -> Identify critical data and configure and activate corresponding logging mechanisms.
- Automate user administration –> Implement Identity, Governance and Administration
- Reduce passwords -> Implement Single Sign-On
I appreciate it, if you let me know via comments, if you need additional or deeper information and what you miss. Of course I like to hear, what you liked too. I care about security and I want you all to be secure and to be able to set up a secure landscape. I hope to help you with this blog.
Gerlinde 