You would not be surprised to hear that another retailer had been hacked and information about many customers was compromised. We hear this kind of information several times per year sensationalized in the media. As these incidents occur there are weeks of investigations to analyze the loss. The team develops an action plan and implements stronger barriers to stop the issue from being a frequent event.
According to the 2014 Verizon Data Breach Investigations Report, two out of three data breaches are related to stolen or misused credentials. There are many ways to obtain these credentials both inside and outside your fortress. Some companies educate employees on phishing to reduce the likelihood of a response. You may also need to send periodic reminders related to effective password protection. To reduce password hacking success rates you may also need to increase password strength. Many companies determine the combination of security parameters that will reduce hacking attempts; they implement the values and walk away hoping to remain out of the news.
With firewalls, secure access zones, and strong passwords you may lose sight that the inside man is estimated to perform over 50% of all data thefts. Do you know if you have a traitor within your walls? A Director of National Sales for your company downloads your annual sales revenue by customer. The following week the Director downloads your customer master data with contact information. As the Director of Sales, these may be normal business activities when performing data analysis. However, when the Director turns in his leave notice a week later these may have been traits of the inside man. Does anyone know what was downloaded? This may have been a Director performing normal business activities or it could be an undetected data loss by someone who planned their exit.
When you think of the inside man, there are many ways we give them access to data. I recently wrote a blog discussing direct table access. http://scn.sap.com/community/security/blog/2014/05/01/reduce-the-risk-of-sap-direct-table-access This blog discusses the authorizations to protect tables. We assign users direct access to data through many reports and programs. These transactions are part of the users approved role assignments. It is very important that this review process is not a rubber stamp exercise to show management approvals. They need to be reviewed for reasonableness as well as proper separation of duties. Many times users are approved access to a process since they are company employees. The process should insure that the access is appropriate for the users’ position. We state in policies that access is assigned on a need to know basis but do you effectively implement a least privilege assignment model? Some estimates document data loss by authorized users as two thirds of all incidents. Users need access to transactions to perform business processes, but this may also enable them to export data into files or spreadsheets at will.
Custom programs are your next hurdle when you are protecting data. It starts with assigning developer keys to developers only. Once development is complete you need an EFFECTIVE code review before transporting changes. This is more than a syntax check. How much time does it take for your experienced developer to review the detailed technical specifications and confirm that what was documented was the only solution delivered? For small changes this may be quick and inexpensive. But do they know how to identify cross site scripting or other vulnerabilities in web enabled applications? Are you removing them from productive work to perform manual analysis? Depending on your environment these code reviews may be ineffective without tools to aide in the review. This is not about endorsing one tool over another but making you aware that ineffective code reviews open holes for data breaches.
Many times hackers expose flaws in commercial software to access data. If all of these holes were closed, do you still have vulnerabilities? Most companies take advantage of enhancement spots within SAP programs or even implement custom code accessing standard SAP tables. Knowing who has access to data through a business transaction or even direct table access may be an easy answer. Knowing who has access through a custom program will be more difficult. How these applications were developed and how they protect access requires an effective code review process. This may even require training for your code review process. A strong technical review of custom code changes is just as important as the user access review. Without a review the developer could be the inside man. Through the use of user exists or function modules to build files, a harmless program may be downloading data under the radar. Even one time conversion programs that remain in your production environment can create risk. You really need to know what tables your custom applications are using.
If you have restricted access to tables, transactions and performed an effective code review, is your fortress protected from data loss? By restricting each of the methods of data access discussed above, there is no magic answer to prevent all data loss. Recently I was made aware of an application used to track data exports from an SAP environment. I will be installing this as a pilot to see how much data is being downloaded by approved users. Some people call it the onion approach since there are many layers of security that must be addressed. You do need to protect direct table access. You must restrict access to sensitive transactions. You need to implement strong security parameters. You even need an effective code review. When sensitive custom applications become obsolete they should be removed to reduce risk of data loss as well. With these obstacles addressed you still need to monitor the insider threat and understand what data is actually being exported from SAP. I will report back once my pilot testing is complete.
