(Source-RSA 2015,USA)
(Source-RSA 2015,USA)
(Source-RSA 2015,USA)
SAP Mobile Platform Security: Introduction
Mobile devices are actively integrated into business processes. Companies have more and more business applications and mobile devices. Employees increasingly bring their own equipment to the workplace (BYOD policy – Bring Your Own Device) and gain access to critical corporate information.
SAP Mobile Platform (or SMP, formerly called Sybase Unwired Platform, or SUP) is a MEAP (Mobile Enterprise Application Platform) solution. SMP is used for monitoring and controlling applications which are installed on mobile phones and have access to business data. The main goal of SMP is providing business data to mobile devices with enterprise security. Platform capabilities allow users to work with data from SAP business applications using mobile applications both online and offline. This data can be accessed through all modern mobile devices. Android, Blackberry, iPhone / iPad and Windows / Windows Mobile devices are used by end users. Installed client applications are connected to SMP. These programs can be found on Play Market, Apple Store, or Windows Store.
SMP security service supports secure connections using SSL between app and server. Data on the device or in-transit can be encrypted using user supplied key. It supports authentication, authorization, access control to various apps and roles, single-sign-on, security audit logging etc. to provide an end to end security from device to the platform.
In order to further secure the access, Mobile Device Management software should be used. All of the security functionality from device to SMP such as SSL, authentication, authorization, and single-sign-on are provided along with the device management, app configurations, and device data security. SMP works with any MDM provider besides Afaria/Mobile Secure for mobile device management.
SMP is also a platform for development. This platform includes tools for rapid development of client applications for various platforms and much more, but let’s focus on risks first.
Risks associated with attacks on SAP Mobile Technology
Risks related to business applications usually include espionage, sabotage, and fraud. Some of the potential risks for SAP Mobile Platform if somebody finds vulnerabilities in this platform and exploits them are provided below:
Vulnerabilities identified by ERPScan researchers:
Now let’s see how real the listed risks are and if there are vulnerabilities which can be exploited to prove that those risks exist. We found multiple vulnerabilities in SAP Mobile Technology including SAP Mobile Platform, SAP Mobile Applications, and SAP Afaria MDM. We will now show 4 of them, which were recently patched by SAP. Each of them is associated with a particular risk described in the previous section. The first two vulnerabilities are server-side and the last two are client-side.
Setting up an Security Incident Response Team (SIRT) is a challenging job.
Things To Keep In Mind:
1.Organization's IT assets and required security measures
2.Log of earlier attacks gives an idea on vulnerable assets and attacks areas
3.Organization's growth and possible immediate future technology threats for them
4. Figuring out major skill sets required in team
5.Ensuring all key departments are present or well-connected in SIRT - Legal,HR,Training,Support,Forensic,Network Analyst,Audit,External support etc.
6.Monitoring is key - Making sure you can identify the incident almost immediately leaves assets very little damaged
Responsibilities of SIRT:
SIRT reports directly to the highest levels of authority at the organization, they own a high stake of protecting the organizational assets. They can often overrule other instructions to handle incidents and protect assets, such is their role. Here are a few:
1.Handle Incidents
2.Protect Information Assets
3.Compliance check
4.Legal checks while dealing with the incidents
5.Monitor and detect incident
6.Restrict the attacks threats and harm to assets i.e. Minimize loss(including reputation)
7.Interpret/Analyse loss due to incident
8.Form and Update policies,procedures to protect asset
9.Treat the incident and revert safe operations again
Incident Response Fundamentals
Prepare - Prepare for an incident, don't wait for it. SIRT and you should be well acquainted with tools
Identify - Monitor and identify the incident and all affected assets or information. Report, send alerts if necessary.
Contain/Isolate - Limit the losses to a minimum by barring the attacks. Isolate the affected assets to resume operations.
Eradicate/Cure - Treat the affected assets and render them harmless or replace if necessary and resume full operations
Recover - Incident needs to be tracked,escalated when required and treated unless complete recovery happens.
With this article we are starting a new series of guidelines describing some basic assessment procedures one can carry out on various business applications that would help security professionals to expand their ERP systems’ immunity to attacks.
As we all know, ERP systems such as SAP may favour the quality of management of all the information and resources involved in a company's operations.
However, while ERP applications promote the way business processes are organized, they also may undermine information security within organizations.
We should not forget how important it is to secure enterprise applications and various ERP systems.
No need to say, that the ERP system is in the core of any large company: it deals with all processes critical for business – purchases, payments, logistics, HR, product management, financial planning etc. All information stored in the ERP systems is sensitive, and any unauthorized access to this information can cause huge damages up to a business interruption.
According to the report[1] by the Association of Certified Fraud Examiners (ACFE), in 2006 - 2010, the organizations losses caused by the internal fraud (the IT-frauds ) amounted to app. 7% of annual revenue [2].
For the last five years, a widespread myth that the ERP security is only a SOD matrix was over, and today this belief seems to become a history for many people. For that time, the SAP security experts have presented lots of detailed reports on various attacks on the internal SAP subsystems:
— the RFC protocol,
— the SAP ROUTER access control system,
— the SAP web-applications,
— the SAP GUI client workstations, and many others.
The interest for this area grows exponentially every year: compared to only 1 report on SAP Security [3] in 2006, more than 30 of such reports were presented in 2013 at specialized hacking and security technical conferences. Lately, a number of hacking utilities were released, and thus confirmed the possibility of attacks on the SAP solutions.
According to the business application vulnerability statistics [4] and [5], more than one hundred vulnerabilities in the SAP products were fixed in 2009, while this figure was more than 500 in 2010. In July 2014, there were more than 3000 SAP Security Notes, i.e. notifications on various SAP components vulnerabilities.
(Read more: My Key Learning While Implementing Database Security)
This entry will help you to get extended info about what is going to come next. And why it is so important to know everything about it.
General information
"The Enterprise Application System Vulnerability Assessment Guide" describes 9 most known business application security areas relating to implementation and operation. This top list was prepared by the authors during vulnerability assessments of multiple business applications; this list may be applied to any of them. These areas are weighty factors for many emerging threats and related attacks. Securing of these areas means getting ready to prevent numerous attacks targeted at business application security.
This series of posts contains a detailed analysis of the most widespread business application platform - the SAP NetWeaver ABAP. During this analysis 33 key settings were identified and distributed between 9 areas mentioned above. This post will show how to protect against the most widespread vulnerabilities in this area as well as provide further steps on securing all 9 areas .
The top-9 critical areas for business applications
Below, you can find the list of Top-9 critical areas for vulnerability assessment of business application. They are ranked from 1 to 9 according to their severity and impact on the ERP system, business applications and related security. For this list, 3 main parameters were considered:
1. initial access to exploit the vulnerability;
2. severity of vulnerability (a potential impact if exploited);
3. complexity of vulnerability exploitation.
This list is the same for all the business applications. In the next chapters, checks for each of these items (specific to the SAP NetWeaver ABAP platform) are described in detail. However, these description are stated in a way to ensure understanding of the basic principles relating to vulnerability assessment for any enterprise application systems.
Critical area | Access | Severity | Simplicity |
1. Patch management flaws | Anonymous | High | High |
2. Default passwords for access to the application | Anonymous | High | High |
3.Unnecessary functionality | Anonymous | High | High |
4. Open remote management interfaces | Anonymous | High | Medium |
5. Insecure settings | Anonymous | Medium | Medium |
6. Unencrypted connections | Anonymous | Medium | Medium |
7. Access control and SOD conflicts | User | High | Medium |
8. Insecure trusted connections | User | High | High |
9. Security events logging | Administrator | High | Medium |
The Guide description
Our approach contains 33 steps to securely configure SAP NetWeaver ABAP platform, that were distributed among 9 areas mentioned above.
The authors' efforts were to make this list as brief as possible but also to cover the most critical threats for each area. This approach is the main objective of this Guide: as despite best practices by the SAP, ISACA and DSAG, our intention was not to create just another list of issues with no explanation on why a particular issue was (not) included in the final list, but to prepare a document that may be easily used not only by SAP security experts. Report should also provide comprehensive coverage of all critical areas of SAP Security.
At the same time, the development of the most complete guide would be a never-ending story as at the time of writing there were more than 7000 checks of security configuration settings for the SAP platform as such, without those of specific role-based access and in-house applications.
As a result, each of the 9 areas includes major checks that must be implemented first and can be applied to any system regardless of its settings and custom parameters. It also important that these checks are equally applicable both to production systems and those of testing and development.
In addition to major all-purpose checks, each item contains a subsection called "Further steps". This subsection gives major guidelines and instructions on what should be done in the second and third place, and then how to further securely configure each particular item. The recommended guidelines are not always mandatory and sometimes depend on a specific SAP solution. On the one hand, with this approach, the authors were able to highlight key security parameters for a quick assessment of any SAP solution (from the ERP to the Solution Manager or Industry Solution) based on the NetWeaver ABAP platform and, on the other hand, to cover all issues and give complete recommendations on them.
In terms of quality, this makes the present Guide different from the SAP best practices that also contain few items, but do not cover the overall picture, as well as from best practices by ISACA and DSAG that have a lot of items, but the priorities are unclear and too complicated for the first step (though these papers are highly valuable and necessary).
(Read more: Database Security Vendor Evaluation Guide)
33 steps to security
So, here it is. Our list of most critical checks for SAP NetWeaver ABAP - based systems
1. Patch management flaws
[EASAI-NA-01] Check for components update (SAP Notes)
[EASAI-NA-02] Check for kernel updates
2. Default passwords for access to the application
[EASAI-NA-03] Default password check for a SAP* user
[EASAI-NA-04] Default password check for the DDIC user
[EASAI-NA-05] Default password check for the SAPCPIC user
[EASAI-NA-06] Default password check for the TMSADM user
[EASAI-NA-07] Default password check for the EARLYWATCH user
3. Unnecessary functionality
[EASAI-NA-08] Access to the RFC-function via the SOAP interface
[EASAI-NA-09] Access to the RFC-function via the form interface
[EASAI-NA-10] Access to the Exchange Infrastructure (XI) via the SOAP interface
4. Open remote management interfaces
[EASAI-NA-11] Unauthorized access to the SAPControl (SAP MMC) service functions
[EASAI-NA-12] Unauthorized access to the SAPHostControl service functions
[EASAI-NA-13] Unauthorized access to the Message Server service functions
[EASAI-NA-14] Unauthorized access to the Oracle DBMS
5. Insecure settings
[EASAI-NA-15] Minimal password length
[EASAI-NA-16] Number of invalid logon attempts before the user account lock out
[EASAI-NA-17] Password compliance with the security policies in place
[EASAI-NA-18] Access control settings for RFC-service (reginfo.dat)
[EASAI-NA-19] Access control settings for RFC-service (secinfo.dat)
6. Access control and SOD conflicts
[EASAI-NA-20] The check for SAP_ALL profile accounts
[EASAI-NA-21] The check for accounts that may start any programs
[EASAI-NA-22] The check for accounts that may modify USH02 table
[EASAI-NA-23] The check for accounts that may execute OS commands
[EASAI-NA-24] Check for disabled authorizations
7. Unencrypted connections
[EASAI-NA-25] The SSL encryption to protect HTTP connections
[EASAI-NA-26] The SNC encryption to protect the SAP GUI client connections
[EASAI-NA-27] The SNC encryption to protect RFC connections between systems
8. Insecure trusted connections
[EASAI-NA-28] RFC connections that store user authentication data
[EASAI-NA-29] Trusted systems with low security level
9. Logging of security events
[EASAI-NA-30] Logging of security events
[EASAI-NA-31] Logging of HTTP requests
[EASAI-NA-32] Logging of table changes
[EASAI-NA-33] Logging of SAP Gateway activities
As you can see – the guide is not as enormous as it could have been due to the complicity of the topic. We tried to maximize the clarity of the guide to security assessments for you.
Stay in touch with us as next week we’ll come back with the new article where the guideline will reappear in its all glory. We’ll provide you with detailed explanation of each step.
(Read more: How effective is your SIEM Implementation?)
-----------------------------------------------------------------------------------------------------------------
This article will be about different guidelines, which can help to secure your SAP system. But nothing to worry about - this post will nevertheless remain useful and interesting, even if it does not contain information about 0-days or have no words like “cyber” or “weapon” in title. So, let’s go.
This blog post will be about new guideline, or standard, for securing - or testing of the security - of SAP implementations, which is going to be a first standard of the EAS-SEC standard series. There were 2 things that push us unto developing this guideline and give a second birth for our project. We thought about making some kind of guideline from the very beginning, and finally made it, when we’ve got a clear idea of how it should be done and what customers really needed.
(Read more: Top 5 Application Security Technology Trends)
And the reason we decided to make this…
… Is simple like one, two three.
One. Questions like "why?" and "what for" are the alpha the omega of every research. For us, as it sometimes happens, the answer came from one more additional question. After implementation of our Security Monitoring Suite for SAP in huge enterprises, making dozens of POC’s and completing numerous penetration tests against SAP systems (as well as other business critical systems), the thing we were asked more often than any other was: “Guys, you are awesome! And you are doing a great job so far, finding so many problems in our installations. It's absolutely fantastic, but we don’t know, where should we start to solve them. Could you provide us with top 10/20/50/100/ [put your favorite number here] most critical bugs in every area?”
Two. At the same time we had to do something completely different from just top-10 of the most critical bugs, like the one, when you can select missing SAP security notes with highest CVSS. Even if you patch all of the notes there still could remain lots of problems. For example, you may have SAP_ALL assigned to every user or you have your logs disabled so that next time, when you forget to close sapnotes, it would be easy to hack your system, because of non comprehensive approach. So, the number one challenge is to understand all security areas of SAP platform and to have an opportunity for every area select a number of most critical issues. So our research first aim was to cover all SAP security areas and be simple to implement - the second one.
Three. We started to analyze existing guidelines and standards. Currently there are not many of them, which cover SAP security and all of them are supported by ERPScan. The guidelines we have are as follows: Secure Configuration of SAP NetWeaver® Application Server Using ABAP by SAP, ISACA Assurance (ITAF) by ISACA, and DSAG by German SAP User Group. All those standards are great, but unfortunately all of them have at least one big disadvantage. But let’s be patient and have a better look. On those standards:
Secure Configuration of SAP NetWeaver® Application Server Using ABAP
First official SAP guide for technical security of NetWeaver ABAP in general. Before it only dozens of specific guidelines for every application were made. The first version of this guide was published in 2010, and was followed by version 1.2 in 2012. As far as it happened almost 2 years ago, we have to put in mind, that in our fast-changing world some critical things could be missing for now. This guideline was created for rapid assessment of most common technical misconfigurations in platform and consists of 9 areas and 82 checks in total.
Advantages: very brief, but quite informative (only 9 pages) and covers application platform issues, applicable for every ABAP- based platform either ERP or Solution manger or HR, it doesn’t matter.
Disadvantages: 82 checks is still a lot for a first brief look on secure configuration. But what’s more important, standard doesn’t cover access control issues and logging and even in platform security miss some things. Finally, it gives people false sense of security if they cover all checks. But it wouldn’t be completely true.
ISACA Assurance (ITAFF)
Probably, the first guideline for SAP Security. Guideline was made by ISACA consortium. There were 3 versions published in 2002, 2006 and finally - in 2009. And it means that 5 years passed from the last release and many areas are outdated now. In general, checks cover configuration and access control areas, application platform security part covers less than access control and miss some critical areas. Guideline consists of 4 parts and about 160 checks in total.
Advantages: detailed coverage of access control checks.
Disadvantages: Outdated. Technical part is missing. Guideline consists of too many checks, and can’t be easily applicable by non-SAP specialist. Also it can’t be applicable to any system without prior understanding of the business processes. And finally, this guideline could be found officially only as part of the book or you should be at least an ISACA member to get it.
DSAG (Deutschsprachige SAP-Anwendergruppe)
Set of recommendations from German-speaking SAP User Group. Checks cover all security areas from technical configuration and source code to access control and management procedures. Nowadays it is a biggest guideline about SAP Security. Last version was released in Jan 2013. Consists of 8 areas and 200+ checks.
Advantages: Ideal as a final step for securing SAP. Great for SAP Security administrators, covers almost all possible areas.
Disadvantages: Unfortunately, has the same problem as ISACA. It is too big for a starter, and no help at all for Security people who are not familiar with SAP. Also it can’t be directly applicable to every system without prior understanding of business processes. Many checks are recommendations and user should think by himself, if they are applicable in each every case.
Fig.1. How SAP security looks like with three guidelines
(Read more: 5 easy ways to build your personal brand !)
What goes around that comes around
So, we didn’t want to make just another security guideline. But also we saw, that all of the current approaches miss something.
Finally we understood that there is a real need in new guideline. Fortunately, now we knew, what we should do to make it not good, but perfect. They all miss one general thing – they are big from one side and still doesn’t cover everything but pretend to do that, which finally gives people false sense of security if they cover all checks
The authors' efforts were to make this list as brief as possible but also to cover the most critical threats for each area. This approach is the main objective of this Guide: as despite best practices by the SAP, ISACA and DSAG, our intention was not to create just another list of issues with no explanation on why a particular issue was (not) included in the final list, but to prepare a document that may be easily used not only by SAP security experts but by every Security specialist who wants to check if his SAP is Secure and guideline should also provide comprehensive coverage of all critical areas of SAP Security.
At the same time, the development of the most complete guide would be a never-ending story as at the time of writing we had more than 7000 checks of security configuration settings for the SAP platform.
We need a guideline, which will consist of few checks, but selected and what’s more important it will have future steps so that everybody will know that they made just a part of a job by implementing the standard, really critical part but not everything. So, we talking about 80/20 rules, and we will implement it in SAP Security.
Result
As a result, of more than 7 years experience in Security assessment of Enterprise Business applications of different types from different vendors including of cause SAP, Oracle, Microsoft, IBM but also taking into account different industry-specific systems like Retailix for Retail, MES/SCADA systems for Oil and Gas and ABS systems in Banking area our broadly experienced Pentest and Research team known for sending 450+ advisories in different products and participating in 50+ events in every continent collected information about most critical vulnerabilities and misconfigurations to understand the most critical areas. Our auditors who were responsible for different certifications like ISO, PCIDSS, PADSS, SOX and NIST in previous work analyzed those business applications from a compliance and risk point of view and finally we got 9 critical areas which are essential for security of every Enterprise Business Application and which are sorted by priority (Based on mix of Criticality, Probability, Popularity and Data needed for conducting attack).
After that we pick most critical vulnerabilities and configurations of SAP NetWeaver ABAP based applications from each of those 9 areas, and finally got 33 most critical checks.
Those are major checks that must be implemented first and can be applied to any system regardless of its, type, settings and custom parameters. It is also important that these checks are equally applicable to production systems and the ones of testing and development both.
In addition to major all-purpose checks, each of 9 critical areas contains a subsection called "Further steps". This subsection gives major guidelines and instructions on what should be done in the second and third place, and then how to further securely configure each particular item. The recommended guidelines are not always mandatory and sometimes depend on a specific SAP solution.
Fig.2. How SAP security looks like with EAS-SEC
Wrap-up
On the one hand, with this approach, the authors were able to highlight key security parameters for a quick assessment of any SAP solution (from the ERP to the Solution Manager or Industry Solution) based on the NetWeaver ABAP platform and, on the other hand, to cover all potential problems and give complete recommendations on them.
In terms of quality, this makes the present Guide different from the SAP best practices that also contain few items, but do not cover the overall picture, as well as from best practices by ISACA and DSAG that have a lot of items, but the priorities are unclear and too complicated for the first step. Though these papers are highly valuable and absolutely necessary as a next steps and they are mentioned in Further steps" areas.
And finally, you are ready to use the guideline itself (click here), made with help of overwhelming experience of ERPScan research team. Read, learn, stay secured!
(Read more: How the Heartbleed bug was found by Antti Karjalainen - discoverer ...)
-------------------------------------------------------------------------------------------------------------------
Today we are going on with our series of articles where we describe the 33 steps to security. The subject is of great significance not only to a small group of SAP infosec specialists, but to all those people who work with ERP systems as recent years have witnessed an increased awareness of business data protection problems. Not to go into details, let us get right to the topic.
The SAP NetWeaver platform includes not only the Dispatcher service responsible for SAP GUI user connections, but it also includes a whole range of other services. Each of them listens to a remote port and accepts network connections. Some of these services grant administrative access and remote administration functions. Some of them also grant access to various technical services. Load balancing system of the SAP Message Server and remote administration system of the SAP Management console are among them.
One can connect to these services via the corporate intranet or the Internet. What is more, in case those services’ settings are insecure, they are manageable remotely without authentication data.
So, this section contains information about the most insecure services. Their settings should by no means be accessible via the corporate intranet.
Further steps
Except those services we are going to discuss, the system has other less critical and widespread services (e.g. the Message Server HTTP). But you should restrict access to them as well. For a full list of SAP services, check out “TCP/IP Ports Used by SAP Applications" paper [1]. The list’s content depends on the installed components of each particular system.
Besides, it is also advisable to check third-party services that may be enabled on this server, such as remote administration interfaces for various DBMS, remote monitoring and data backup systems, etc. The thing is that you should restrict access to them using authentication both at the network and application levels, if possible.
[EASAI-NA-11] Unauthorized access to the SAPControl (SAP MMC) service functions
Description
The SAP Start Service starts on each computer simultaneously with the SAP solution instance. In Windows, this process is executed with sapstartsrv.exe, in UNIX - with sapstartsrv. The SAP Start Service provides the following functions for the SAP solution, instance and process monitoring:
These services are accessible via the SAPControl SOAP Web Service and are used by the SAP monitoring tools (SAP Management Console, NetWeaver Administrator and others). When service starts, it uses the following ports:
For example, when service starts, either the HTTP port 50013 or the HTTPS port 50014 is used for the instance 00. [2]. This process allows to read various system data without user's consent. However, it requires user authentication for secure operations, such as to start or stop the SAP instance. Startsrv controls internal list of secured operations (depending on the version of the release, default list may differ). If necessary, you can change the list using service/protectedwebmethods parameter.
Threat
By means of many insecure methods, one can get access to system configuration data, request system status, read the log and trace files that may contain user passwords or HTTP session files. Eventually, this data can be used to implement more critical attacks.
Solution
In accordance with SAP Note 1600846 [3], sapstartsrv settings must be reconfigured. To do this, you need to set the parameterservice/protectedwebmethods to DEFAULT in a default system profile (DEFAULT.PFL). To apply the changes, restart all sapstartsrvservices in the cluster. Besides, this change of value, also involves implementation of a list of all critical methods by default. Instead, you can use the value ALL (i.e. all methods), though it is considered excessive (the parameter and its values are described in detail in SAP Note 927637 [4]).
Implementation of SAP Note 1439348 [5] along with related recommendations may be seen as an additional method of patching this vulnerability.
It is advisable to restrict access to this service by IP-addreses. To do this, you need to define Access Control List (ACL) by changing values of services/http/acl_file and /https/acl_file.
[EASAI-NA-12] Unauthorized access to the SAPHostControl service functions
Description
The SAP Host Agent is a component designated for other components management, their control and monitoring. It consists of the following services and programs:
A profile used while starting executable files also determines whether sapstartsrv will run in an instance operating mode (with an appropriate instance profile) or in a host mode (with the host's own profile that may include parameters SAPSystem = 99, SAPSystemName = SAP). [6]
For data transmission, the SOAP protocol is used. In case encryption is set up, it encapsulates into the SSL. This service allows to read some system information without user’s consent. It also has vulnerabilities that allow to run OS commands remotely.
Threat
An authorized adversary can run any random code, caused by the SAPHostControl service maintenance error remotely using the SAP NetWeaver. This happens when this service does not properly validate incoming data of the SOAP management interface. With the SOAP interface running on TCP port 1128, an adversary can exploit this vulnerability to inject and execute random commands to the system having administrative privileges.
Many insecure methods make system configuration or status data requests possible. One can also read logs and trace files that may contain user passwords or HTTP session files. Also, remote execution of OS commands using OS command injection vulnerability becomes available (see SAP Note 1341333 [7]). This data can be used to implement more critical attacks.
Solution
Remote execution of random code vulnerability was fixed in May 2012 with SAP Security Note 1341333[8].
SAP Security Note 1816536 [9] released in April 2012 prevents information disclosure. Resulting from this, it’s sufficient to apply both of these security updates to fix vulnerabilities.
In order to additionally secure the service you can restrict access to it by IP, using a personal firewall or by means of network equipment, granting access only from those servers where you take data from.
[EASAI-NA-13] Unauthorized access to the Message Server service functions
Description
The SAP Message Server is a system component that, on the one hand, manages communication between application servers (dialog instances) within one SAP system and, on the other hand, ensures balancing of a load coming from such clients as the SAP GUI.
In standard, lower than 7.0 versions, Message Server port is used for interaction of both clients and application servers. Starting from the version 7.0, Message Server port is by default divided into an internal and an external port. An internal port is used for application connections to the server, while an external port is used for end-user connections.
In order to control the list of addresses one can connect to the Message Server with, you need to activate the Access Control List (ACL). To do this, use ms/acl_info parameter. It indicates the file where you can configure access to the Message Server. This file contains application server's host and domain names, IP addresses and/or subnet masks using which you can access the Message Server. External clients that retrieve data from the Message Server are not anyhow affected by this. The data remains accessible. Default parameter value is /usr/sap/<SID>/SYS/global/ms_acl_info.
Threat
In case ACL file is absent or misconfigured, malicious software or potential adversaries can access the Message Server, register their own application server and perform "man-in-the- middle" attacks. In other words, intercept credentials of legitimate users trying to connect to the Message Server. This can result in gaining unrestricted access to user accounts.
Solution
It is essential to configure ms/acl_info parameter. It indicates the ACL file that has an authorized access to the Message Server. (default value: /usr/sap/<SID>/SYS/global/ms_acl_info). This file should contain application servers' host and domain names, IP addresses and/or subnet masks from which application servers are allowed to address the Message Server. They address the Message Server using the following syntax:
HOST = [*| ip | hostname | network mask | domain ] [, ...]
Configuration file accepts the "*" wildcard in access control description (e.g., HOST = *.sap.com or HOST = 157.23.45.*). The "*" wildcard should be avoided, especially when in the HOST = * form, as it makes access from any workstation possible.
Access control settings do not affect the retrieval of technical information from the Message Server. It remains always accessible.
As an alternative to ACL file configuration we suggest the following options:
[EASAI-NA-14] Unauthorized access to the Oracle DBMS
Description
Currently, Oracle Data Management System (DBMS) is the most widely spread DBMS along with the SAP. Unfortunately, if installed together with the SAP, this DBMS has insecure REMOTE_OS_AUTHENT settings. REMOTE_OS_AUTHENT ensures execution of trusted operations between various SAP solutions.
More importantly, it is able to circumvent such security checks, in particular DBMS password check. The only way to mitigate this risk is to restrict remote access to Oracle DBMS port by preserving it only for necessary servers by IP addresses.
This setting is implemented by means of the Sqlnet.ora configuration file. In particular, it has to do with tcp.validnode_checkingparameter, which is required to validate host names while they attempt to establish inbound connections. When this parameter is set to yes value, inbound connections are only allowed if they come from the note listed in TCP.INVITED_NODES orTCP.EXCLUDED_NODE. Note that, the first one is of higher priority.
TCP.INVITED_NODES, in turn, requires each client host to be included in the sqlnet.invited_nodes server list.
Threat
If restrictions for client nodes are not set, an attacker can connect to the Oracle DBMS without password, using a trusted login$OPS<SID>adm. Thus, the attacker will get almost unlimited access to the DBMS.
Next step is to decrypt SAPR3 user password. One can take it from the SAPUSER table and connect to the DBMS with this user’s privileges. This user has a full access to the SAP data, thus an adversary can get an unlimited control over the system.
Solution
Set the tcp.validnode_checking parameter in the sqlnet.ora file to “ yes. This way it’s possible to check whether there are inbound connections coming from the permitted nodes listed in sqlnet.invited_nodes.
It’s imperative to specify all the necessary client hosts in the sqlnet.invitednodes server. It is recommended to leave only the trusted systems in this list.
-----------------------------------------------------------------------------------------------
Third critical area. Unnecessary functionality
What is the most common problem of any more or less complex application? In essence, they almost always have numerous unnecessary functions aimed to perform multiple tasks.
Obviously, that makes the whole system vulnerable. The more functionality is available, the higher becomes the number of vulnerabilities. "Complexity Kills Security"
More importantly, all those functions are enabled by default right from the start, thus making security threats inevitable. However, there is a growing trend that in every next following version of SAP there are positive changes concerning unnecessary functionality as more and more safety measures are being taken (extra functions are now deactivated by default).
Besides, very often those are not the functions themselves that make the whole system subjected to treats. It is evident that only those additional functions that are misconfigured can perform critical actions.
So, that is why it is crucial to regularly carry out security checks for misconfigured unnecessary functions. This critical area is the third one in our list and it involves three security assessment steps:
But first, let us start with the basis. Web-applications and internal system objects (such as programs, transactions, RFC, etc.) - that is where most unnecessary functions are typically concentrated.
As far as it is quite easy for low-privileged or even anonymous users to get access to web-applications via the Internet, the decision was taken to describe in the present article only the checks related to web-applications.
Also, when it comes to the ways of getting access to web-applications we should keep in mind that it is the Internet Communication Framework (ICF, the SAP Web Application Servercomponent) that makes it possible to implement standard protocols, such as HTTP, HTTPS and SMTP for intersystem connections management via the Internet.
Further steps
Standard environment contains about 1500 various web-services that are available remotely on behalf of any registered user. Also, about 40 services are accessible to anonymous users. Note that remote access is only possible if the service was enabled by default.
Besides, after you have completed the three checks mentioned in this article, you should also disable all the services that anonymous users can get access to. Secondly, you should analyze all the installed services in order to detect those of them are not necessary for the system. Lastly, restrict access to the necessary ones using additional authorizations.
Check out «Secure Configuration of the SAP NetWeaver Application Server Using ABAP» [1]. In this paper 13 critical services are indicated. As mentioned above, those are only the main, basic services.
Another step to be taken, after you have completed web-services configuration is disabling all unnecessary internal functions, such as unnecessary critical transactions, programs, profiles, roles, etc. This step requires a thorough analysis of each module in each particular case.
Nevertheless, there are several transactions within the productive system to be disabled (1 see the paragraph end). They are mentioned in ISACA guides[2].
For the record, in the present guideline we only recommend you to do this, this item was not included in the main list because it only has to do with productive systems.
Transactions recommended to be blocked (disabled):
[EASAI-NA-08] Access to RFC-functions via the SOAP interface
Description
RFC stands for Remote Function Call. Accordingly, RFC is a SOAP-interface based service which allows to get remote access to some of the functional modules, also called RFC-functions. This service is available by the following link: /sap/bc/soap/rfc.
Firstly, you need to have /sap/bc/soap/rfc service activated. Secondly, you need to have legitimate system or default user with a default password available in the system. In this case, it becomes possible to access and execute RFC-functions of the ABAP platform.
Threat
One can start RFC-function execution via HTTP channel using SOAP requests. Sometimes SOAP requests are even sent from the Internet.
An adversary can use default account details to gain access to RFC service. Subsequently, having access to RFC crevice one can carry out various types of attacks. For example, a regular user with any set of privileges can perform a DoS attack using incorrect SOAP request.
Solution
Providing that you have /sap/bc/soap/rfc service activated, make sure that the number of users allowed to access RFC is somehow restricted. Whereas, if there is no real need to use RFC, deactivate it using SICF transaction.
[EASAI-NA-09] Access to the RFC-function via the form interface Description
When it comes to /sap/bc/FormToRfc service, we should bear in mind that this service is intended only for internal needs of SAP. It should be by no means kept within the production system. The reason is that this service misses some authorization checks. Starting from the version 6.20, this service's functions are performed by the SOAP (/sap/bc/soap/rfc). As regards to ICF services, they are disabled by default.
Threat
It is risky to use /sap/bc/FormToRfc service within the production system, as it lacks some authorization checks. One can exploit this vulnerability using RFC-function, and get an unauthorized access to any business data.
Solution
In case the /sap/bc/FormToRfc service is not used, it is highly recommended to deactivate it with the help of SICF transaction.
[EASAI-NA-10] Access to Exchange Infrastructure (XI) via SOAP interface
Description
SOAP interface based surface which is used to access the so-called Exchange Infrastructure (XI) may be implemented to remotely call some critical functions. Moreover, it allows to send requests to a third- party system.
Threat
On the condition that the service was activated incorrectly or the number of restrictions is insufficient, it becomes possible to start execution of XI-function via HTTP channel using SOAP requests. Sometimes SOAP requests are even sent from the Internet.
An adversary can use default account details to gain access to this service. In this case one can carry out various types of attacks, both on the target system and on those systems that are integrated with it depending on the type of performed function, which is set in the Enterprise Service Bus. In the worst-case scenario, an adversary may get an unlimited access to this server together with the related ones.
Solution
In case the service is not used, it is highly recommended to deactivate it with the help of SICF transaction. Otherwise, it is better to set up additional access restrictions. To do that, you should put into practice the use of appropriate authorizations or network access control procedure.
Summarizing our discussion let us once again remind you of the fact that presently no ERP system is immune to security threats. There is no exception to this rule. That is why solid information should be regularly provided on how to rise security control to higher levels.
Next time we'll come back with a description of new security assessments procedures concerning the fourth critical area from our list. Bye, and remember to keep a wary eye on business data.
-------------------------------------------------------------------------------------------------------
Second critical category. Default passwords for access to the application
For the two previous weeks we’ve been discussing the top-9 critical areas and the 33 steps to be taken for security assessment. Ultimately, we’ve covered patch management flaws - the first critical category in our list. As you should have probably guessed, today it’s time we take a closer look at the next item from our list of critical issues - default passwords.
It is a wide reaching vulnerability with multiple attack vectors. As it requires little skill, default passwords vulnerability exploitation is now among the most frequently used ways of getting access to company’s data. Once installed, SAP system has several standard clients: 000, 001, 066. They all have high privileges set by default (usually, they have the SAP_ALL profile). When it comes to creating new clients, SAP system automatically generates default usernames and passwords.
In the version 6.10 of SAP Web Application Server, the so-called Master Passwords [1] were first put into practice.
Users should be particularly careful, as the fact is, vendor's default accounts and their passwords are well known. Have a look at the following table; we’ve gathered default passwords here for you:
USER | PASSWORD | CLIENT |
SAP* | 06071992, PASS | 001, 066, Custom |
DDIC | 19920706 | 000, 001, Custom |
TMSADM | PASSWORD, $1Pawd2& | 000 |
SAPCPIC | ADMIN | 000,001 |
EARLYWATCH | SUPPORT | 066 |
(Read more: Can your SMART TV get hacked?)
Further steps
Some additional SAP components also have their unique default passwords. For example, old versions of such services as SAP SDM and SAP ITS have their own pre-installed default passwords.
After you have finished checking whether there are default passwords, you should check user passwords for simple dictionary passwords. We suggest that you use efficient password bruteforcing utilities, in particular, such utilities, as John The Ripper would fit you great. Alternatively you can use ERPScan Security Monitoring Suite.
Besides, default passwords should be checked in all associated systems. Don’t forget to check your network equipment, operating systems and DBMS that store SAP system data. Oracle DBMS, for instance, contains a lot of default passwords, including those specific for SAP systems.
[EASAI-NA-03] Default password check for a SAP user
Description
The SAP* users are created in all clients immediately after installation. Those are dialog users who work via SAP GUI (user type = dialog). They perform all administrative tasks (and usually have the SAP_ALL profile). In case any SAP* user has been removed, after the system was rebooted one can login using standard PASS password and get all the corresponding SAP_ALL privileges.
Threat
Default passwords of SAP* users are well-known (see the table above). With these passwords, an adversary may enter the system using SAP_ALL profile and, consequently, get an unlimited access to any business data stored in the system.
Solution
EASAI-NA-04 Default password check for the DDIC user
Description
The DDIC user is created in the clients 000 and 001 upon their installation (and copying). This default system user’s purpose is to perform system installation, renewal, configuration and operation. Its purpose can also be implementation of support packages, upgrade and background job runtime of Transport Tool background jobs triggered by the tool.
In case the client is 000, this user belongs to a dialog type, it has the right to enter the system via SAP GUI and perform any actions.
In all the other clients it is a system type user, it may perform background processing and it can interact with the system. SAP_ALL and SAP_NEW profiles that grant access to all the functions of the SAP are defined for this user.
Threat
The DDIC user default password is well-known (see the table above). With these passwords, an adversary can enter the system using SAP_ALL profile and, consequently, get an unlimited access to any business data stored in the system.
Solution
WARNING! Do not remove the DDIC user or its profile! The DDIC user is necessary for performing certain tasks, such as installation or updating. It can also interact with ABAP dictionary. The DDIC user removal results in a loss of functionality in these areas. But it is acceptable (and highly recommended by some resources) to remove it in all clients except 000.
[EASAI-NA-05] Default password check for the SAP user
Description
The SAPCIPIC user is used in transportation system of SAP solutions (in 4.5A and lower versions). It is a communication type user. It is mostly used for EDI (Electronic Data Interchange). It may also transport RFC calls without dialog boxes.
So, this user does not have dialog type user privileges, though it has the S_A.CPIC profile. As a result, critical are the following authorization objects:
(Read more: How to choose your Security / Penetration Testing Vendor?)
Threat
Default passwords of SAPCPIC user is well-known (see the table above). With these passwords, an adversary can remotely execute RFC requests (e.g. start some OS programs); execute arbitrary OS commands through RFC vulnerabilities (e.g. TH_GREP); create dialog users with any privileges to enter the system and get an unlimited access to the data.
Solution
Remove SAPCPIC user if you do not need it. If the user is still necessary:
[EASAI-NA-06] Default password check for TMSADM user
Description
The TMSADM user is used for transfers through the transport system. It is created automatically upon configuration and changes of Transport Management System (TMS) via the 000 client.
It is a communication user, in other words, it is often used falsely to transport external RFC calls without dialog boxes. It has the assigned S_A.TMSADM authorization profile enabled to utilize RFC-functions with GUI and to write to a file system. SAP_ALL profile is also often assigned to this user.
Threat
The default password of TMSADM user is well-known. An adversary may remotely start RFC requests to perform critical actions such as deletion and reading files (EPS_DELETE_FILE, EPS_OPEN_FILE2); arbitrary ABAP code execution (through the RFC_ABAP_INSTALL_AND_RUNor TTMS_CI_START_SERVICE function vulnerabilities), and, using BAPI_USER_CREATE1 andSUSR_RFC_USER_INTERFACE requests, to create a dialog user and, consequently, to enter the system and get an unlimited access to business data.
Solution
Additionally, it is better to apply security notes related to vulnerabilities in the programs which TMSADM user can execute, such as:
[EASAI-NA-07] Default password check for the EARLYWATCH user
Description
The EarlyWatch user is created in the 066 client upon SAP installation and is related to a dialog type. It can enter via SAP GUI and perform any actions to the system. One can use it for SAP distance remote management and to get access to monitoring data. As a rule, it is used by SAP AG customer support to enter customer's systems. Change the default password forEarlyWatch user, but never delete the user.
Threats
EarlyWatch user’s default password is well-known (see the table above). With this password, an adversary can enter the system using the S_TOOLS_EX_A profile and, consequently, perform various critical actions (for example, access any files, view sensitive tables or display external statistics records via the control tools). In old versions - 6.4 and lower, users could execute critical transactions such as SE37 (function modules execution) and SE38 (running reports). In the new versions, it has fewer privileges, but it can exploit some vulnerabilities, such as theTH_GREP call with the SM51 transaction and, consequently, execute arbitrary OS commands.
Solution
Warning!Do not remove Earlywatch user or its profile!
By now you should have noticed the ease and clarity with which we tried explain to you some technical subjects. You should also have noticed and wondered how we managed to make the list of critical issues that brief. You may even have marveled at how sometimes we point out what it all means, what it’s good for, and why should you care. It’s completely up to you, but if you like our articles we strongly recommend that you stay with us as in two weaks well come back with the descriprion of the next critical issue.
(Read more: Shellshock Bug: A Quick Primer)
-------------------------------------------------------------------------------------
First critical issue. Patch management flaws
In our previous articles we’ve already introduced you to the list of the 9 most important business application security critical issues. We’ve also had a chance to present to you the skeleton of our guideline with its 33 security assessment steps. As you’ve seen only the skeleton of it, now it’s high time to pay attention to a more detailed explanation of each step to be taken.
In order to insure full-scale system security it is crucial to regularly install security support packages. The number of support packages necessary for a system may be huge. Supporting this idea is the fact that the number of SAP Security Notes grew up to more than 3000 by the mid-2014. As some of you may know, each Sap Security Note serves to fix one or more vulnerability. About 50 Security Notes are issued monthly. Sometimes one can even find a SAP Security Note that was made based on the results of a third-party researcher’s work [1]. Also, when it comes to prompt vulnerability elimination we should take into consideration all the possible consequences implementation of such utilities as Metasploit to get free access to corporate information can lead to. Given the above arguments, it is reasonable to conclude that to develop and establish a patch management process that would ensure the implementation of adequate preventive measures against potential threats is highly necessary at this stage. Let us now focus on the two major checks that must be in place to address the most critical problems.
(Read more: APT Secrets that Vendors Don't Tell)
Further Steps.
To verify security of SAP components, particularly those of them that are installed separately from the application server you can use such services as SAP Router, SAP Webdispatcher, SAP GUI. Additionally, it’s convenient to use those systems that are linked to the NetWeaver ABAP application server, but operate on the basis of the NetWeaver J2EE or SAP BusinessObjects application servers. Their security is regulated by a separate document included in the EAS-SEC. It’s substantial that, a security patch should be checked for operating systems where SAP services are installed, as well as for DBMS that store SAP solution data.
[EASAI-NA-01] Check for components update (SAP Notes)
Description
The essence of the whole patching procedure is that a patch is designed to substitute outdated and vulnerable objects. There are two ways to fix a vulnerability: one can either implement the correction instructions from an SAP Note in the system, or have a Support Package installed. As a rule, initially a particular SAP Note (with appropriate correction instructions) is issued. After that, a Support Package is applied. The Support Package usually contains changed or new functionality with a set of correction instructions for a certain period of time.
As mentioned above, the number of support packages and SAP Notes required by the system may be huge. That's why the development of patch management process should also involve establishing a priority of patch installation. While determining the right priority one should consider the following factors:
WARNING! Sometimes vulnerability management processes can mix up. That is to say, vulnerabilities may be fixed with either a support package, or with the help of the SAP Notes. The matter is, they won’t synchronize. For instance, a vulnerability fixed with a support package would not be implemented as fixed via the SNOTE transaction to the SAP Notes list.
(Read more: 5 Security Trends from Defcon 2014 - The Largest Hacker Conference)
Threat
As soon as there appears a new security patch, newly identified vulnerabilities rather quickly become publicly available. To put it another way, anyone can gain access to their description. Accordingly, in case security patch was implemented after a long period of time it gives an adversary a chance to exploit those vulnerabilities, to get an unauthorized access to sensitive business data.
Solution
It is imperative to perform regular checks for security patches updates. To do that, one should strictly follow main patch management process steps (data collection, risk assessment, implementing security patch software, result monitoring). Using SAP Patch Manager (SPAM)offered by the SAP one can download and implement required support packages from theOnline Server System (OSS). Note that this is only related to versions 3.0 and higher. In order to start the SPAM, you should enter the command “SPAM” in the transaction code field.
Also, it’s possible to use the multi-purpose SAP Software Update Manager (SUM) to implement various system updates. The good news is that a demo version of this product is publicly available at the time [2]
To implement SAP Notes, use the SNOTE transaction to get a list of security notes required for a particular system. As mentioned above, these two mechanisms are not synchronized, so it is preferable to make some changes manually or with some additional third-party tools.
Before proceeding to our next security check let us make a small digression. The thing is we’ve decided to be proactive in terms of information security, thus in addition to major all-purpose checks, each item of our guideline contains a subsection called "Further steps". This subsection gives major instructions on how to further securely configure each particular item.
[EASAI-NA-02] Check for kernel updates
Description
We should keep in mind that in SAP system kernel there are executable files containing SAP Dispatcher, SAP Gateway, SAP Message Server, SAP Router and some other SAP services. For that reason, SAP system kernel has its own update mechanism that is different from other components. Kernel updates are released as service packs for a specific kernel type.
So as to clarify, support packages are cumulative. Therefore they include all the previous updates, even though sometimes releases contain updates for a certain support package only.
Threat
As soon as there appears a new security patch, newly identified vulnerabilities rather quickly become publicly available. To put it another way, anyone can gain access to their description. Accordingly, in case security patch was implemented after a long period of time it gives an adversary a chance to exploit those vulnerabilities, to get an unauthorized access to sensitive business data.
Kernel updates mostly fix highly critical vulnerabilities, as any system has a kernel. So, it’s crucial that kernel update should have highest priority and should be installed before other components.
Solution
It is imperative to perform regular checks for security patches updates. To do that one should strictly follow main patch management process steps (data collection, risk assessment, implementing security patch software, result monitoring).
In case you want to check out the current version of a service pack using SAP GUI you need to open the Status window in System tab and click on the Other kernel info button (Shift+F5 by default). There is always some information on the latest service pack version published on the SAP support portal[3]
The SAP Note is usually downloaded as a system and executable files directory that replaces the previous files. Software Update Manager (SUM) utility is also available to facilitate the manual process a lot (ref. to the operating manual [4]).
That’s it for today’s article, we’ve checked out the first critical issue “patch management flows” and the two steps relating to it. We hope you like our work and share our urge to promote information security to a higher level.
(Read more: Technology/Solution Guide for Single Sign-On)
---------------------------------------------------------------------------------------------
Each application has several security settings that do not fit into any of the critical issues groups mentioned in our series of articles.Among such settings there are both standard settings (such as password length or the number of attempts given to enter invalid password) and the specific to the system, individual settings. In this article we are going to use as an example the SAP Gateway service access settings.
[EASAI-NA-15] Minimal password length
Description
While choosing a new user password, consider that passwords should meet the SAP system requirements and correspond to the corporate policy. Various profile parameters are set up in order to control that passwords meet the requirements. Out of all those parameters, login/min_password_lng is the main one. It specifies the allowed minimal password length. This parameter’s default value is 6, although its acceptable to use values ranging from 3 to 40.
Threat
In case the minimum password length is set to less than 8 symbols, an adversary can easily decrypt a password using USR02 table hash. Alternatively, one can gain access remotely by bruteforcing the password, if the login/fails_to_user_lock parameter is set incorrectly. The login/failstouserlock parameter defines the number of available invalid login attempts, before the user’s account is locked out by the system.
Solution
Set the login/min_password_lng parameter value for more than 8, otherwise choose the value which is in accordance with the company’s security polity. This way, you can lessen the risk of potential attack.
[EASAI-NA-16] Number of invalid logon attempts before the user account lock out
Description
The login/fails_to_user_lock parameter defines the maximum number of incorrect passwords allowed to be entered before the user account is locked out. It’s very important as it interacts directly with the login/min_password_lng parameter. Thelogin/min_password_lng parameter, in turn, defines the minimum password length, and thus, prevents remote password bruteforcing. This parameter’s default value is 5, although it’s acceptable to set values ranging from 1 to 99.
Threat
If the login/fails_to_user_lock parameter is set incorrectly or has a low value, an adversary may succeed in carrying out a brute force attack and get an unauthorized access to user credentials.
Solution
Set the login/fails_to_user_lock parameter value for not more than 6. This way, you’ll lessen the risk of potential brute force attack.
[EASAI-NA-17] Password compliance with the security policies in place
Description
The login/password_compliance_to_current_policy parameter is highly important. If this parameter is absent or or is set to 0,the password length and complexity settings would affect only newly created users. Thus, the settings would not be automatically applied to all the other users. Consequently, all of those old users would have insecure passwords.
If this parameter is set to 1, the settings would affect old users with insecure passwords and force them to choose secure ones upon their logging into the system.
Threat
If the login/password_compliance_to_current_policy parameter is set to 0, password policy compliance for old users is not set. This allows users to have insecure passwords. As a result, these user accounts are easy to be compromised.
Solution
Set the login/compliance_to_current_policy parameter to 1 to apply the password policy requirements for all users, including those newly created.
[EASAI-NA-18] Access control settings for RFC-service (reginfo.dat)
Description
The SAP Gateway is the application server technical component with RFC-based functionality that manages communications between various SAP systems. Since the gateway is an interface of application server for external connections (with other SAP systems, external programs, etc.), higher security requirements are applied to it.The SAP Gateway security is managed by the reginfo and thesec_info files. The reginfo file is defined by the gw/reg_info parameter and the sec_info file is defined by the gw/sec_infoparameter.
Some clients may be allowed to register their services on the server. Specify the services registered in the reginfo file to control the access to them, cancel their registration, determine external server services allowed to be registered on the gateway. The file name (file path) is defined by the gw/reginfo parameter. The default file path is: /usr/sap/<SID>/<INSTANCE>/data/reginfo.
If this file doesn’t exist, any server processes may be registered from any hosts. Speaking of which, starting from the kernel version 7.20 and higher, for security purposes, this process is restricted by the gw/acl_mode instance profile parameter. For further references, see SAP Security Note 1480644 [1]. However, if this file exists but it is empty or has no valid records, it is not allowed to register.
If somebody tries to register a service on the gateway, valid record is searched for in the file. The record specifies this user’s right to register this particular service. If the record is not found, user’s registration is denied. It is crucial to understand that the reginfo file can be read only ONCE, when a program is being registered. All the further changes and restrictions in the reginfo file do not affect successfully registered programs.
Threat
In case the reginfo.dat file is absent or its configuration is incorrect, an adversary may register any service on the SAP Gateway and get an unauthorized access to the SAP server. As an example, a wildcard “*” can be used in host definitions, signifying that service’s registration is available from any host. One may register a new service that would perform malicious functions. It may be registered under the same name, as has the service that already exists. Thus, a legitimate user would be able to run it.
Solution
Unauthorized service registration may be avoided by means of creating a reginfo.dat file in the SAP Gateway data directory. If the file exists, the system checks the availability of rights to call remote RFC functions from this file. This way, it prevents unauthorized access.
File records should have the following syntax (note that each line must have TP record, all the other parameters are optional):
TP=name [NO=<n>] [HOST=<host>] [ACCESS=<host>] [CANCEL=<host>], where:
TP=name is a registration ID of the external server program.
NO=n shows what number of registrations with that ID is allowed.
HOST=<host> is (a) name(s) of a host using which registered servers are allowed to enter the system. Here you may specify host names’ list, IP addresses, domain names or subnet masks. The registration is allowed only if the server enters the system from this node. Without this optional parameter, it is allowed to register from any host.
ACCESS=<host> is(are) host name(s) that has (have) the right to use the registered service. Here you may specify the list of host names, IP addresses, domain names or subnet masks. The local system is always allowed to use the server. Without this optional parameter, the server is accessible from any node.
CANCEL=<host> is(are) (a) host name(s) that allow(s) to log off the registered system server. The same rules are applied as has theACCESS parameter.
Starting from the version kernels 6.40, patch 212; 7.00, patch 139; 7.10, patch 80, and higher, permit and deny values are added to the syntax. They are indicated by the Latin upper-case letters P and D respectively (see SAP Security Note 1105897 [2]). P means that a program is allowed to be registered, (as in the old syntax line); D prevents registration. The first line layout in such file is#VERSION=2. All the next lines are structured the following way: P|D TP=name [NO=<n>] [HOST=<host>] [ACCESS=<host>] [CANCEL=<host>]
Warning! The system reads key words only if they are written in upper-case letters. Incorrect specification leads to HOST=* wildcard value, which would probably be undesired (there are instructions on how to fix it in SAP Security Note 1473017[3]).
In all the host names’ lists (HOST, ACCESS and CANCEL), key words must be separated by commas. Any space would indicate the end of host names’ list.
You can find detailed syntax review in SAP Security Note 1069911 [4].
For the correct reginfo.dat configuration use recommendations from SAP Security Note 1425765 and 1408081. [5][41], [6].
[EASAI-NA-19] Access control settings for RFC-service (secinfo.dat)
Description
In the secinfo file, you may specify which external services may be started. Also, you can specify who can register external server services on the gateway. And lastly, which external services can be registered on the gateway. Note that this concerns only kernel versions 46D and lower. Starting from the version 6.40, service registration from external servers is controlled with a separateRegInfo file. In other words, secinfo security file is used to prevent unsanctioned start of an external program. File name is defined by the parameter gw/sec_info. Default file path is: /usr/sap/<SID>/<INSTANCE>/data/secinfo.
If the file does not exist the system runs all external programs. In case, this file is empty or has no valid lines, no external service may be started.
Upon the start of an external service, the system scans the file, searching for a valid record. If it was not found, the system shows error message, and cancels the service start.
Threat
In case secinfo.dat file is absent or misconfigured (e.g., it has “*” wildcard in host, program of subnets definitions), an adversary may run a service registered in the SAP Gateway, and get an unauthorized access to its functionality. In some cases, if the program can execute OS commands, one may access the SAP server.
Solution
You should create secinfo.dat file in the SAP Gateway data directory. This way it would be possible to prevent unauthorized program launching. If the file exists, the system checks the availability of rights to call remote RFC functions from this file. This way, it prevents unauthorized access.
File records should have the following syntax ( USER, HOST and TP lines are obligatory, and other parameters in each line are optional):
TP=name HOST=<host> USER=<user> [USER-HOST=<user-host>], where:
TP=<program name> is the name of a program, you would like to run (in addition, you can specify a wildcard for program ID, e.g.,TP=XYZ*)
HOST=<host> - name of the host where you would like to run a program. It defines destination address. Note the following difference: in the reg_info file syntax, this parameter specifies client address; it is available starting from the version 6.40, patch 194; 7.00, patch 119 and higher versions.
USER=<user> is the name of the user who would like to start a program. In case the program starts from application server, this is username for the system. However, if the program is external, this is OS username.
USER-HOST=<host> (or a source address) is a hostname of the user who would like to start a program. For security purposes, it is strongly recommended to install this option (SAP Security Note 1434117 [7]).
In 6.40 and lower versions, PWD=<Password> parameter was supported (ignored in newer systems).
In 6.40, patch 212; 7.00, patch 139; 7.10, patch 80, and higher kernel versions, there appeared additional permit and deny values indicated by the Latin upper-case P and D respectively (see SAP Security Note 1105897 [8]). P permits to run the program (the same as the old syntax line); D denies it. The syntax of the first line in such file is #VERSION=2, and that of all posterior lines is:
P|D TP=<tp> HOST=<host> USER=<user> [USER-HOST=<userhost>]
Warning: the system reads key words in the upper-case only. Incorrect specification leads to the HOST=* wildcard value, which is undesired. (there are guidelines on how to fix it in the SAP Security Note 1473017[9]).
For detailed explanation of this syntax check out the SAP Security Note 614971 [10][44].
For the correct secinfo.dat configuration refer to SAP Security Notes 1408081, 1525125, 1425765. [11][12][13]
Further steps.
The number of various security settings to be fine-tuned is enormous, and there are specific ones to each particular SAP solution or module. As the starting point, you can refer to the document called SAP NetWeaver Security Guide. There you can find the User Authentication section. Afterwards, you better switch to a more detailed description of the papers where each module and service security configuration is described.
-----------------------------------------------------------------
Error
Why current SAP Security Guides Always Provide So Little Help? - 'click here' not working
We are thrilled to have received so many wonderful ideas and suggestions during the breakfast series specifically focusing on CPI findings. Here are the quick highlights!
What was the objective of the Community Breakfast?
About CISO Platform Index
CISO Platform Index (CPI) - Index developed based on User Satisfaction Survey by CISOs who used the vendor product on different evaluation metrics. Click here to know more.
About Vendor evaluation checklist
Every CISO creates their own checklist to evaluate vendors, however mostly a basic framework can be found common and reduce huge effort duplication. CISO Platform is working with other CISOs & domain experts to create Vendor Evaluation Checklists for 20 major security domains. Click here to know more
( Read more: Top 5 Application Security Technology Trends )
Community Feedback on CPI during the Meetup
Community Feedback on Vendor Evaluation Checklist
( Read more: Top 5 Big Data Vulnerability Classes )
Few Photographs:
Mumbai
Delhi
Bangalore:
More: Join the community of 2000+ Chief Information Security Officers. Click here
(Read more: Annual Survey on Cloud Adoption Status Across Industry Verticals)
Quick Glimpse
Fairly technical content with demos where Jacob Holcomb speaks on Internet Of Things, Threat Modelling and Possible Remedies.
What will you Learn:
View Presentation/PPT:
(Read more: Security Technology Implementation Report- Annual CISO Survey)
Based on Type of Attack:
Based on Type of Activities:
http://www.sans.org/reading-room/whitepapers/incident/incident-response-fight-35342
http://www.bu.edu/tech/services/security/services/incidents/reporting/types/
For Organization Chart & Module click here
Roles & Responsibilities of IR Team
IR Management-
IR Core Team-
Communication team-
Public Relations Officer-To tackle any public or media inquiry, this should be the resolving point. Communication is main as Incidents will pass on brand value and it is best done by the public relations officer or team.
IR Technical assessment & Forensics team-
Technical Support Team or IR Support Team-
(Read more: How effective is your SIEM Implementation?)
Secondary IR Team(HR,Legal,Training)-
CSIRT Team pg 23 http://www.sans.org/reading-room/whitepapers/incident/creating-mana...
http://resources.sei.cmu.edu/asset_files/Handbook/2003_002_001_1409...
http://www.sans.org/reading-room/whitepapers/incident/implementing-...
https://technet.microsoft.com/en-us/library/cc700825.aspx
http://www.sans.org/reading-room/whitepapers/incident/computer-inci...
Incidence Resp. & Forensics-Johnson 111
6steps in Incident Response Process:
Escalation - When an incident is not yet tackled, based on its priority, it is escalated to a higher level. This enables business to focus more of its resources to the incident and solve it,always based on priority.
----///not required*
Types of Escalation
----///not required*
Categorize Incidents on Priority based on :
----draw chart----
///--*not required--
Pre-requisites of Escalation
----not required----*//
Levels of escalation:
Level 0/low:
Level 1/medium:
Level 2/high:
Level 3/critical:
Eg. of escalation in Tulane university
Example of Escalation levels in montana college & health institute:
(short brief from the pges)
https://www.mtech.edu/cts/policies/policies/escallation.pro..pdf
http://security.calpoly.edu/docs/standards/incident-response.pdf
ref:
http://www.slideshare.net/agnihotry/itil-incident-managementfor-beginners pg6
http://countuponsecurity.com/2012/12/21/computer-security-incident-handling-6-steps/
http://searchsecurity.techtarget.com/definition/incident-response
mohd. ref:-
http://www.slideshare.net/agnihotry/itil-incident-managementfor-beginners
(other usable links)-
https://federation.edu.au/__data/assets/pdf_file/0006/34656/Escalation-process-diagram.pdf
http://wiki.en.it-processmaps.com/index.php/Checklist_Incident_Escalation
CISO Platform presents an exciting opportunity to listen to Hugo Teso, who recently “created global news by demonstrating how an aircraft can be compromised and remotely controlled by using an android phone"!
Thought this webinar is super exciting and here's a blog for it.
Watch Video(Webinar by Hugo Teso):
View PPT:
Key Points:
Delhi is the capital of India and is almost the northern center. It is easily commutable to various popular spots in India, specially the Himalayan Range, Pink City Jaipur, Thar desert and Historical sites like Taj Mahal,Red fort, Kutumb minar etc. Here's a concise list so you can plan ahead:
1. Taj Mahal:
Often mentioned in 'Wonders of the world' & a UNESCO World Heritage Site is One of the greatest Mughal Architectures in history, built by emperor Shah Jahan. It has been the object of study for years! Did you know it took ~22 years and ~20,000 artisans & craftsmen to complete?
Images(from top left clockwise)- Taj Mahal, Kutumb Minar, Hawa Mahal
2. Himalayan Range:
3. Thar Desert or Great Indian Desert:
World's 17th largest desert & 9th largest subtropical desert.It extend through Aravalli Hills,Great Runn of Kutch & Indus River. It's diverse fauna includes Chincara or indian gazelle, Bengal Fox,blackbuck etc.
4. Historical sites(local sites) in Delhi:
First 3 are UNESCO World Heritage sites.
References:
http://en.wikipedia.org/wiki/Taj_Mahal
http://en.wikipedia.org/wiki/Thar_Desert
http://en.wikipedia.org/wiki/List_of_tourist_attractions_in_Delhi
http://www.transindiatravels.com/delhi/15-rejuvenating-hill-stations-near-delhi/
Read more: Top 5 Application Security Technology Trends
Read more: 5 easy ways to build your personal brand !
Read more: How the Heartbleed bug was found by Antti Karjalainen - discoverer of Heartbleed
Read more: Top 5 Big Data Vulnerability Classes
Read more: How to write a great article in less than 30 mins
Read more: Cyber Safety in Cars and Medical Devices
Read more: 5 Best Practices to secure your Big Data Implementation
Read more: How Should a CISO choose the right Anti-Malware Technology?
Read more: 7 Key Lessons from the LinkedIn Breach
Read more: Under the hood of Top 4 BYOD Security Technologies: Pros & Cons
Read more: BYOD Security: From Defining the Requirements to Choosing a Vendor
Read more: Hardware Trojans: Sneak Peek into the Future
Read more: My Key Learning While Implementing Database Security
Read more: Database Security Vendor Evaluation Guide
Read more: How effective is your SIEM Implementation?
Read more: Technology/Solution Guide for Single Sign-On
Read more: Action List Before Adopting a Cloud Technology
Read more: CISO Guide for Denial-of-Service (DoS) Security
Read more: Can your SMART TV get hacked?
Read more: How to choose your Security / Penetration Testing Vendor?
Read more: Shellshock Bug: A Quick Primer
Read more: APT Secrets that Vendors Don't Tell
Read more: 5 Security Trends from Defcon 2014 - The Largest Hacker Conference
Read more: Technology/Solution Guide for Single Sign-On
Read more: Annual Survey on Cloud Adoption Status Across Industry Verticals
Read more: Annual Survey on Security Budget Analysis Across Industry Verticals
Read more: Security Technology Implementation Report- Annual CISO Survey
Read more: Checklist to Evaluate A Cloud Based WAF Vendor
Read more: Checklist to Evaluate a DLP Provider
Read more: Checklist for PCI DSS Implementation & Certification
Read more: Checklist to Evaluate IT Project Vendors
This is a great Big Data webinar(15 min), hosted by CISO Platform and briefly points out the Security Challenges and also Recommends Some Fixes. It is presented by Head of Development at Iviz.
What will you learn:
- Key Insights on Existing Big Data Architecture
- Unique Security Risks and Vulnerabilities of Big Data Technologies
- Top 5 Solutions to mitigate these security challenges
Watch the 15min Power Webinar:
(Read more: Technology/Solution Guide for Single Sign-On)
View Presentation/PPT:
3 Major Subheads Covered:
Key Insights on Big Data Architecture
Top 5 Big Data Security Risks
Top 5 Best Practices
(Read more: CISO Guide for Denial-of-Service (DoS) Security)
This is a great Man In the Browser Attack webinar(15 min), hosted by CISO Platform and briefly points out the Risks and also Recommends Some Fixes. It is presented by the CTO at Iviz. MiTB being particularly important for banking and finance Industry.
What will you learn?
- Learn why MiTB attacks pose a high risk to online banking and why is it hard to detect
- How Man In The Browser' Attack Bypasses Banks' Two-Factor Authentication Systems
- How one can mitigate the risks of MiTB attacks
Watch the 15min Power Webinar:
(Read more: My Key Learning While Implementing Database Security)
View Presentation/PPT:
(Read more: Database Security Vendor Evaluation Guide)
Quick Glance:
Attack Scenarios-
Reasons of Danger-
How to Protect as End-user-
Mitigation Strategy for Bank-
(Read more: How effective is your SIEM Implementation?)
2014 has been a great year at CISO Platform. We had around 1500 new senior executives joining the platform and published 120 new articles on security. Here are some of the best ones from 2014.
Checklist to Evaluate A Cloud Based WAF Vendor |
Checklist to Evaluate a DLP Provider |
Contrary to the common man belief that 'Windows is very insecure', Microsoft has been very proactive in security. Apple iOS has a great deal of security too, it is described in its building from scratch in the iOS security document. Here are the few points I found great for mention. Here's a small video which has the debate on.
Watch video[9 min]:
(Read more: Top 5 Big Data Vulnerability Classes)
Microsoft(Windows)
Apple(iOS)
* We have mentioned a few, this is a suggestive list not binding, there are various other features.
What are best security specs in your favorite mobile OS- Windows or iOS ?
(Read more: Cyber Safety in Cars and Medical Devices)
Watch Video:
(Read more: Under the hood of Top 4 BYOD Security Technologies: Pros & Cons)
Ants and Elephants in the CISO's Office by Paul Rain
I will show how ISO 9001 and ISO 27001 can be used together to deliver business value and demonstrate to executive management and key stakeholders that you are exercising due diligence in protecting your organisation's information assets. The talk will briefly discuss the requirements of the two standards and show how ISO 27001 and ISO 9001 can be used to address both the tactical challenges of information security (the ants) as well as the strategic challenges of delivering business value (the elephants).
View PPT:
(Read more: Hardware Trojans: Sneak Peek into the Future)
Watch Talk:
(Read more: 5 Best Practices to secure your Big Data Implementation)
BadUSB — On accessories that turn evil by Karsten Nohl
Karsten Nohl is a cryptographer and security researcher
This talk introduces a new form of malware that operates from controller chips inside USB devices. Peripherals can be reprogrammed in order to take control of a computer, exfiltrate data, or spy on the user. We demonstrate a full system compromise from USB and a self-replicating USB virus not detectable with current defenses.
View PPT:
(Read more: 7 Key Lessons from the LinkedIn Breach)
Here is an interesting webinar on the 'Insecurities of Security Products'. More often we consider the security vulnerabilities in products apart from security products. It is ironic how a product devised to provide security can also make you more susceptible to compromise. How-So will be demonstrated through a few examples.
3 Industry experts had joined us in this webinar-
*Note the webinar was conducted in 2013, thus the information related to persons are as per the webinar timing.
(Read more: Checklist to Evaluate IT Project Vendors)
What you will Learn:
How security products can be exploited
Vulnerability trends in security products over last decade
Vulnerability statistics of Major Security Vendors /Products
Classes of Vulnerabilities in Security Products and comparative analysis
Watch Webinar Video (Scroll Down For Slides) :
(Read more: Checklist to Evaluate a DLP Provider)
A Quick Glimpse of the Webinar Topics Covered:
Examples of Security Products with Vulnerabilities
Report/Study
The Comparative Analysis reveals an interesting insight, security products are least vulnerable to 'SQL Injections' while highly vulnerable to 'Access Control','Input Validation' etc issues compared to all other products.
View Presentation