In every developer`s life the moments come that change your perspective Change the way you build your code, the way you analyze things before building them or what are the post-development activities of yours. (Since I don’t dare to blog for security specialists, I will describe rather simple things without many details so this blog(s series) can be used by the beginners and other not yet security aware folks). In the following lines I will try to name the moments that were important for me and my professional development and how the security perspective fits into the picture.
Eye opener #1: SAP standard
First eye opener was the vast possibilities and opportunities of using SAP standard DDIC objects, reports and function modules (if you`re interested in my opinion on SAP standard and reusability of code, read other two blogs of mine called: Celebration of the SAP standard code for dummies Celebration of the SAP standard code for dummies, part 2) .
Ok, that is obvious, but after leaving school with only experience with stuff like C++ you`re not really used to do this. STL for C++ is far from the wide SAP standard. Why do I name such obvious thing? It is because that as the time goes I am able to write less and less code on my own and achieve things I want to achieve by calling the SAP standard tools in the right order, with right arguments etc.
This is not relevant to security very much, but it took me years to get rid of my fear of debugging the whole depth of SAP standard code and reuse what already exists heavily. One of my most important pieces of experience with heavily reusing SAP standard is very much connected with the development I am working on right in the last weeks and months – security tools and enhancements.
If you`re a beginner, try this as soon as possible, don’t be afraid, it will speed up your skills very much and will make you a better SAP developer.
Keep in mind that any code monkey can move values from variable to variable. Other things than that makes you a valuable member of the team
Eye opener #2: Performance aspects
Eye opener number two was the performance aspects of the development. When one develops something, he/she decomposes the task into small pieces and builds a method, a report or a function module for each of the pieces. When you do this with your eyes (or brain) closed, you use something like SELECT SINGLE and then call the method in LOOP and performance goes to h…Holywood.
Another obvious fact. But as a developer you do small logical units testing all the time, so you test that method for a single call. Or if you have time or do your job properly, you then test the whole development together to see what happens. Then a slight slowdown can appear. Pfff 0,1 s or 0,2 s makes no difference. But then a situation appears that you transport your development to the test system and then to production system and it stops working. Why? Because there are zillions of records you have to process in the production system, but the number of records processed in DEV and QAS was like thousand times lower. Yes, that was quite an eye opener.
Eye opener #3: Security
And here it comes. Security. The third and the last important “eureka” moment so far was about Security. Why? Simple. How much do you think about the security of your development? How many AUTHORITY CHECKs do you implement? None? Few? I don`t know any developer that would protect his/her development the way the true security consultant would say “hey, good job, very precise” (could be a rivalry, not the bad way of programming, but still…). How many authorization objects do you know? There are hundreds of them, nobody knows all of them (unless you`re the “object search help”…). But one should know at least few: the most important ones, the most critical ones, the ones tight with your favorite application area.
How do you protect your code so it cannot be misused through the debugger?
What do you do to make your code quickly usable by the users, because it is obvious which role does the user needs? (well, you don`t give your users the code but an application, but I know many developers who give users or managers the code, they don`t care about applications or anything which starts with the word “business” like “business case” or “business user”). Do you provide roles for your development or you have to be asked to do that and then ask for days/ weeks to build the roles? Have you ever used SU24, so you provide SU24 proposals for your development?
I don`t want to sound offensive. I know many developers who do most of this or their employers have some processes in place so the workload is split. But not many who do everything I named above (and there is much more to do regarding the secure development). Please don`t feel offended. There are too many of those who don’t get the underlying concepts or have no experience (or even no initial training), so they don`t do things. That`s why I name the things here.
Another favorite example of mine (personal experience) is about RFCs and workflows. What users do you use for your RFC and workflow scenarios? ALEREMOTE with SAP_ALL? WF-BATCH with SAP_ALL? Careless development cause so much overhead if you want to fix things later (documentation? I will write some after the go-live. Security? Let`s talk about that after the documentation is finished. Sounds familiar?). It causes much vulnerability in your system. Obvious. So start thinking about your processes and ways you and your work team now.
Motivational example: Do you like having cold? I don`t. So I try to eat some fruit and all those things as a daily routine instead of trying spending days out-of-order. And that`s very much the same as with the security. Better safe than sorry.
Cheers Otto
- SAP Managed Tags:
6 Comments
