Cyber Attacks Archives - Page 4 of 12

SAP Vulnerability Assessment vs Penetration Testing

Layer Seven on September 19, 2019

Vulnerability assessment and penetration testing both serve important functions for protecting business applications against security threats. The approaches are complementary but should be deployed sequentially. Penetration testing against systems and applications that have not been hardened based on the results of vulnerability assessments is inadvisable since the results are predictable. The objective of penetration testing is to assess the strength of security defenses, not to exploit ill-equipped and unprepared systems and processes to prove a point.

Therefore, vulnerability assessments should be performed ahead of penetration tests. The results of comprehensive vulnerability scans inform organizations of configuration, program, user and other weaknesses that could be exploited to compromise systems during real or simulated attacks. The recommendations resulting from the assessments enable organizations to remediate security weaknesses using a prioritized approach. It also supports the implementation of counter measures to detect and respond to potential attacks.

Once systems are hardened and defenses are prepared, performing a penetration test is a valuable exercise to test the adequacy of security mechanisms. The lessons learned from the discovery and exploitation of vulnerabilities during penetration tests can be applied to address areas that may have been overlooked or inadequately secured after vulnerability assessments. Penetration testing against hardened systems that are actively monitored for attacks forces pen testers to exercise more complex and difficult attack vectors. It also compels pen testers to deploy evasive techniques to avoid detection. This improves the quality of penetration tests and the reliability of the results, providing a stronger litmus test for system security, threat detection and incident response.

Monitoring Security Alerts with SAP Solution Manager

Layer Seven on August 14, 2019

There are several apps available in SAP Solution Manager for monitoring security alerts for SAP systems. The most longstanding is the Alert Inbox which provides an overview of alerts by process area. Guided procedures for investigating security alerts are executed from the Alert Inbox. Another option is System Monitoring which provides a more user-friendly interface for navigating incidents than the Alert Inbox. System Monitoring includes the Alert Ticker displayed in the right pane of the app for monitoring incidents in real-time.

SAP Solution Manager 7.2 SP07 introduced a third option for monitoring alerts called Monitor Systems. The app is delivered in the new work center Application Operations.

System Monitoring and the Alert Inbox are Web Dynpro applications. Monitor Systems, however, is a SAPUI5 application based on the Fiori framework. Therefore, Monitor Systems delivers exceptional performance with alerts loading and refreshing at much faster rates than both the Alert Inbox and System Monitoring. The performance gains are considerable even for SAP Solution Manager installations running on conventional databases rather than SAP HANA.

You can access Monitor Systems from the SAP Fiori Launchpad using the roles SAP_STUI_APPOPS_AUTH and SAP_STUI_APPOPS_TCR.

The initial screen summarizes alerts open alerts by systems and components.

Alerts are categorized by the groups below. Security alerts triggered by the Cybersecurity Extension for SAP Solution Manager are categorized in the Configuration and Exception classes.

Results can be filtered or sorted by clicking by system and category.

Systems can also be labeled as favorites for fast selection.

You can view details of open alerts for each system by clicking on the system. Below are alerts for security configuration issues impacting system AS2.

Below are security exceptions detected through real-time monitoring of event logs in the system.

We can drill down into the details of each alert by clicking on Critical Metrics. For example, we can investigate the alert below for the Actions by the Standard SAP* User Alert by reviewing the relevant metric.

The Metric Details reveals that there was an attempted logon with the SAP* user from IP address 10.8.91.2 at 12:51 on 2019-08-14. We can execute a guided procedure that will investigate other actions from the source IP directly in the Security Audit Log.

The results can be shared with security operations teams through email by clicking on the Notify option in the Metric Details.

In another example, we can drill down into the alert for active users logged into the system with SAP_ALL in their user buffer to investigate potential privilege escalation. The profile should not be used in productive systems.

Recommended Settings for SAP Logging and Auditing

Layer Seven on July 25, 2019

The Cybersecurity Extension for SAP Solution Manager monitors SAP event logs to automatically detect and alert for indicators of compromise. The monitoring interval can be customized for each security metric based on risk and sizing. An interval of 60 seconds, for example, can support real-time threat detection. However, real-time detection is only useful when supported by real-time incident response. Organizations that lack rapid response capabilities should opt for collection intervals of 10-15 minutes to balance the need to minimize the mean to detect (MTTD) with the system impact of continuous monitoring.

Log settings also need to be carefully maintained to capture security-relevant events while preventing the accumulation of log data and the consumption of excessive disk or table space. The recommended settings and archiving procedures below for each log area will enable you to maintain comprehensive forensic logs with minimal system impact.

Security Audit Log
Maintain static filters to log all actions by the standard SAP* user, logons and transaction starts by the DDIC user, and Severe and Critical events for all audit classes and users. Also create a static filter to log the non-critical event IDs BU4, CUY, DU9, DUI, and FU1. The filters should be applied to all clients. If you have yet to remove the EarlyWatch client, also create a filter to monitor events for all audit classes and users in client 066.

Periodically export events older than 30 days using transaction SM20. Once the events are successfully exported and backed-up to a file server, trigger the background job RSAUPURG to delete events older than 30 days using transaction SM18.

Read Access Log
Configure or import logging purposes to log access to sensitive fields and tables including user tables. Archive SRAL objects using transaction SARA. RAL archives can exported and stored offline.

Change Documents
Change documents for user changes are triggered automatically. Similar to the Read Access Log, change documents are archived using transaction SARA.

Business Transaction Log
There are no specific settings required for STAD. Since data is retained for only 48 hours, STAD archiving is also not required.

System Log
Similarly, the system log does not require any specific settings or archiving. The system log is a ring buffer. When the log file reaches its maximum size, the system overwrites the oldest data.

HTTP Log
The LOGFORMAT option for HTTP logging should specify a format that includes the URL in log entries. An example is the CLF format. HTTP log files in the /usr/sap/SID/instance/work directory can be exported and archived offline.

Gateway Server
The ACTION option for gateway logging should include the actions SsZMP to capture security events, configuration changes, and monitor commands. Gateway log files are can also be found in the work directory of each instance and archived to an external location.

Java Security Log
The value of the following properties should be set to TRUE to include the client host address, object name and actor in logged events: ume.logon.security_policy.log_client_hostaddress, ume.secaudit.get_object_name, and ume.secaudit.log_actor. Automatic archiving should be activated using the Log Manager. Once activated, the compressed archives can be found in usr\sap\<SID>\JC<Instance number>\j2ee\cluster\<Dispatcher or server>\log\archive.

HANA Audit Log
The target audit trails should be set to CSTABLE and SYSLOGPROTOCOL to log events simultaneously to internal tables and the OS-level system log. Audit policies should be configured to log critical actions including all actions performed by the SYSTEM user, system changes, user changes, role changes, repository changes, and unsuccessful logons.

The contents of the AUDIT_LOG table can be exported using the AUDIT OPERATOR privilege in the HANA Studio. Once exported, navigate to the Auditing tab in the Security section and select the option to truncate the audit trail.

For detailed step-by-step instructions, refer to the section on Log Settings and Maintenance in the user manual for the Cybersecurity Extension for SAP Solution Manager.

Webinar Playback: Holistic SAP Cybersecurity with CVA & SolMan

Layer Seven on June 20, 2019

Watch the pla yback of this month’s webinar to learn how you can implement holistic cybersecurity for your SAP systems with Code Vulnerability Analyzer and Solution Manager.

CVA performs static code analysis to detect vulnerabilities in custom code. SAP Solution Manager detects vulnerabilities and threats in SAP systems including components such as the gateway server, message server and SAProuter, targeted by the recent 10KBLAZE exploits.

Together, CVA and Solution Manager provide an integrated platform to secure custom code and SAP systems against cyber threats.

10KBLAZE: Secure Your Systems with SAP Solution Manager

Layer Seven on May 13, 2019

On May 2, the Department of Homeland Security issued an alert for SAP customers in response to the disclosure of new exploits targeting vulnerable SAP components. According to some reports, the so-called 10KBLAZE exploits could impact 90% of SAP installations worldwide. The exploits target misconfigurations in the gateway server and message server installed in most SAP systems including S/4HANA, ERP and CRM. The successful execution of the exploits could enable attackers to exfiltrate or modify data and provoke a denial of service without authentication. In other words, attackers can completely compromise target SAP systems without any user credentials.

The new exploits target known vulnerabilities addressed by notes and advisories released by SAP since 2005. Note 821875 details measures to secure the message server, including restricting external access, separating internal and external communications, and maintaining secure access control lists. The profile parameter ms/monitor should be set to 0 to prevent external programs such as msmon from administering the message server at the operating system level. Access to transaction SMMS should also be restricted since the setting can be changed dynamically using the Message Server Monitor within the application server. A separate port for internal communication between application servers should be defined using parameter rdisp/msserv_internal. This will prevent external clients from intercepting or rerouting internal message server communications. The port should not be exposed to clients or intranets. Finally, the parameter ms/acl_info should specify the file containing a restrictive access control list of hosts, domains, IP addresses or subnets for application servers permitted to log on with the message server.

ACLs should also be defined for the gateway server to control access to starting external programs. This can be performed using the gateway security file sec_info. The correct syntax for the file depends on the kernel level. For kernel 7.20 and higher, the setting USER-HOST=LOCAL is recommended to protect against 10KBLAZE exploits. This will allow connections from the same server instance. The setting USER-HOST=INTERNAL could be vulnerable but is required for SID clusters. For detailed guidance, refer to Note 1408081. The ACLs should be supported by the setting gw/acl_mode to 1. This parameter defines the behavior of the gateway server if sec_info does not exist.

Since some 10KBLAZE exploits are targeted at modifying or redirecting data packets, enabling SNC to authenticate and encrypt client-server communications is recommended.

SAP systems vulnerable to 10KBLAZE exploits can be discovered using SAP Solution Manager. The Cybersecurity Extension for SAP Solution Manager automatically monitors security settings for the message server and gateway server including profile parameter settings, access control lists and users with critical transactions such as SMMS. The extension also monitors message and gateway logs for external monitor commands, successful and unsuccessful program starts, and other events. Alerts are triggered by the extension for suspected exploits.

The example below illustrates how you can discover insecure sec_info entries that could expose systems to 10KBLAZE exploits.

Click on Vulnerability Report in the Fiori Launchpad.

Filter by ABAP systems, select the check-box for the target system and click on Display.

Filter for vulnerabilities in open status within the area of RFC Security. Click on the check for starting of external programs.

Review the details and recommendation. Click on the linked SAP Notes and SAP Help.

Click on Additional Information to review the insecure entries in the sec_info ACL.

Focus on entries with the setting USER-HOST=internal.

Click on the download icon to export the current settings.

If required, add comments in the Comment section.

The finding for the system will be automatically removed from the report once the sec_info entries are updated. However, you can manually change the status using the Change Status option. Note that status changes are tracked in the extension.

You can also assign responsibility for remediating the finding to specific groups using the Change Owner option.

Webinar: 10KBLAZE – Secure Your SAP Systems with CVA and SolMan

Layer Seven on May 9, 2019

According to a recent report, thousands of SAP installations may be vulnerable to 10KBLAZE exploits targeting SAP applications.

Join SAP and Layer Seven Security to learn how to secure your SAP systems against the exploits with SAP Code Vulnerability Analyzer (CVA) and SAP Solution Manager. CVA performs static code analysis to detect vulnerabilities in custom code. SAP Solution Manager detects vulnerabilities and threats in SAP systems including components such as the gateway server, message server and SAProuter, targeted by 10KBLAZE.

Together, CVA and Solution Manager provide an integrated platform to secure your business-critical SAP systems against 10KBLAZE and other exploits.

Thu, Jun 6, 2019
11:00 AM – 12:00 PM EDT

Securing Administrative Access in SAP AS Java

Layer Seven on April 25, 2019

The misuse of administrative privileges is a common method used by attackers to compromise applications and propagate attacks to connected systems. The elevated privileges granted to administrative accounts are a prized target for attackers and provide a fast path to accessing or modifying sensitive data, programs and system settings.

User privileges for Java applications are administered through the User Management Engine (UME) in the SAP NetWeaver Application Server for Java (AS Java). The UME is the default user store for AS Java and can be configured to use LDAP directories, AS ABAP, or the system database of AS Java as the data source for user-related data.

UME permissions granted to users can include administrative actions such as Manage_All, Manage_Roles, Manage_Users, Manage_User_Passwords, and other privileged functions. Administrative actions are bundled into roles and granted to users organized into user groups. Standard user groups include the Administrator group, as well as groups such as SAP_J2EE_ADMIN and SAP_SLD_ADMINISTRATOR. The latter includes users with administrative access to the System Landscape Directory. Standard roles include Super Admin and, for Enterprise Portals running on AS Java, Portal System Admin, Portal User Admin and Portal Content Admin.

Access to administrative roles and rights in AS Java should be granted to required users only, based on the principle of least privilege. Users with administrative privileges in AS Java systems can be detected using the Cybersecurity Extension for SAP Solution Manager. The results are displayed in security reports and dashboards. Alerts are also triggered by the extension for new users granted privileged roles and actions for possible privilege escalations. The extension also detects users with administrative rights in ABAP and HANA platforms, as well as SAP-compatible databases including IBM, Microsoft, Oracle and Sybase.

Code Vulnerability Management with SAP Solution Manager

Layer Seven on March 10, 2019

Custom Code Management (CCM) in SAP Solution Manager can enable you to take control of custom developments by providing transparency into custom objects in your SAP systems and analyzing the usage of custom code. It can also provide insights into security vulnerabilities in custom objects and packages.

CCM provides an overview of the custom developments in systems and identifies unused or redundant code based on usage statistics from Usage and Procedure Logging (UPL). Decommissioning entire programs or specific lines of code within programs if they are unused or redundant can minimize the attack surface and ensure that time and effort is not wasted managing code-level vulnerabilities in custom developments that are not serving a business need.

Decommissioning in CCM is complemented by tools such as the SAP Clone Finder which identifies custom code that is cloned from SAP standard and supports reverting back to standard code, wherever possible.

CCM displays the results of code checks performed using the ABAP Test Cockpit (ATC). This includes findings from SAP Code Vulnerability Analysis (CVA). CVA performs static application security testing for custom ABAP developments. The tool is used by SAP to scan and secure SAP-delivered code. Therefore, it enables SAP customers to enforce equivalent standards for the security of custom code as enforced by SAP for standard code. Note 1921820 provides details of the security checks performed by CVA. The details are also available in the SAP Community Network.

Enabling CCM is a prerequisite for monitoring the results of CVA checks in SAP Solution Manager. However, CCM is only available to Enterprise support customers and therefore is not available for customers on Standard support. Details of usage rights for Solution Manager are available at the SAP Support Portal.

Licensing restrictions prevent all SAP customers from integrating CVA results with Solution Manager to support holistic cybersecurity monitoring that includes managing risks at the system, user, event and code level.

Layer Seven Security’s custom data connector for CVA resolves this issue by integrating CVA findings directly with the Configuration and Change Database (CCDB) in Solution Manager. This avoids the dependency on CCM and Enterprise support. The data is extracted by the connector from each target system to Solution Manager and automatically updated on a daily schedule. The extracted data is integrated with security reports, dashboards and alerts in Solution Manager to support centralized monitoring for cyber risks in SAP systems including vulnerabilities in custom code. The CVA connector is bundled with the Cybersecurity Extension for SAP Solution Manager.

The raw data for CVA results can be viewed in the custom CCDB store ATC_RESULTS. Results include the check ID, object name, package name, developer name, impacted lines, and a description of each finding.

The findings are mapped to service level reports, web-based reports, and security dashboards in Solution Manager.

CVA results are also integrated with security alerts and email/ SMS notifications generated by SAP Solution Manager.

Cyber Espionage Warning: 30% Growth in Targeted Attacks

Layer Seven on February 25, 2019

The findings of the annual Internet Security Threat Report indicate that the number of organizations targeted by advanced hacking groups increased by almost one third between 2015 and 2018. The groups have not only substantially increased their cyber-espionage operations, they are also deploying increasingly sophisticated tactics against a growing number of sectors. National hacking groups such as Chafer and cross-national groups such as Dragonfly are conducting highly targeted campaigns to gather intelligence and exfiltrate data from organizations.

Chafer is linked to the use of leaked NSA exploits and is credited for several attacks against telecoms and transportation companies and their supply chains. Dragonfly has targeted primarily energy and utility companies including infiltrating the control systems of power supply systems. Other groups such as Gallmaker have been responsible for attacks against government institutions and military organizations.

Hacking groups are no longer relying on malware delivered through spear-phishing or other exploits to carry out attacks. Rather, they are using publicly available tools to execute targeted cyber-espionage campaigns. This includes tools such as Metasploit which provides tools and utilities for exploit development and deployment. Metasploit includes numerous modules for SAP exploits. Approximately 39 percent of intrusions in 2017 did not deploy any malware. The use of publicly-available tools with legitimate purposes can obfuscate attacks and prevent detection.

Despite the growing sophistication of attacks, average breakout times across all intrusions and threat actors more than doubled between 2017 and 2018 from 1 hour and 58 minutes to 4 hours 37 minutes. This is according to the 2019 Global Threat Report. The breakout metric measures the average time taken by attackers to escalate or propagate an initial compromise to other targets in a network. The increase in breakout time suggests that organizations are more effectively hardening potential targets against exploits and detecting and isolating attacks. However, the overall average masks substantial differences between threat actors. Russian threat actors have an average breakout time of just 18 minutes and 49 seconds. This means organizations typically have under 20 minutes to discover and contain attacks from Russian hacking groups. Average breakout times are lowest for Russian, North Korean and Chinese hacking groups and highest for cyber criminals.

Successfully detecting and containing cyber intrusions relies not only on speed of detection but also speed of response. Real-time or near-time threat detection should therefore be supported by effective incident response mechanisms to investigate security breaches. SAP Solution Manager provides an integrated platform for both threat detection and incident response. SolMan connects directly to event logs in SAP systems as often as every 5 minutes to detect and alert for security breaches. It also provides automated procedures for investigating and tracking incident response. To learn more, contact Layer Seven Security.

Database Security with the Cybersecurity Extension for SAP

Layer Seven on January 30, 2019

Protecting SAP systems against cyber threats requires integrated measures applied not just within the SAP layer but across the technology stack including network, operating system, and database components. As repositories of business-critical and sensitive information, databases warrant specific attention for hardening and monitoring efforts. This includes identifying and addressing configuration weaknesses, excessive privileges, and weak audit policies, encrypting data in transit and at rest, removing vulnerable stored procedures, and detecting and responding to privilege abuse or escalations.

SAP Solution Manager is uniquely positioned to monitor the security of SAP databases given its deep connectivity into SAP platforms. This article outlines the architecture and data collection procedures for database monitoring with Solution Manager. Next month’s article will explore database-level security reporting and event monitoring with SolMan.

Establishing connectivity to databases supporting SAP systems is a standard step during the mandatory configuration procedures for Solution Manager. Connection information is entered into the DB Parameters section during the Enter System Parameters step of Managed System Configuration. This includes the database host, port, and user credentials.

The connection supports the DBA Cockpit for database administration and monitoring. It also supports database extractors used by the Extractor Framework. The Extractor Framework performs data collection and distribution for monitoring and alerting in Solution Manager. The framework operates regular extractors to snapshot configuration, user, system, change and event-related data from systems. The snapshots are stored in areas such as the SolMan Configuration and Change Database (CCDB) and queried by other applications in SolMan including Configuration Validation and the Monitoring and Alerting Infrastructure (MAI). The concept of running or scheduling security scans is foreign in Solution Manager. Periodic jobs run the extractors to refresh the data. Therefore, there is no need to schedule scans or connect directly to systems to compile data when reviewing security-related information. Job Monitoring in Solution Manager can be used to monitor the relevant jobs and alert for job errors or warnings.

Solution Manager automatically applies preconfigured templates for databases once they are successfully connected for monitoring. SolMan installations are packaged with templates for all platforms supported by SAP systems including SAP databases such as HANA, Sybase and MaxDB, and third-party databases from Oracle, IBM and Microsoft. Template contents can vary based on the specific version and release of databases.

Templates for HANA platforms including metrics and alerts for monitoring system availability, performance and security. They also include CCDB stores to extract current values for HANA parameters, and details of active users, audit policies and users with critical database and system privileges.

The extractor framework and SAP-delivered templates may not provide coverage for monitoring all the security-related areas for each database platform. Therefore, customers or partners can either define their own templates or create/ modify extractors, metrics, alerts and CCDB stores to extract additional data. In the example below, we’ve added several custom stores to extract and query data for Sybase ASE that is not available in a standard Solution Manager installation. This includes runtime values for all Sybase parameters, active users, roles assigned to database users, enabled stored procedures, audit settings, and database event logs with event IDs, user IDs, and timestamps.

The stores are assigned to the custom /L7S/ namespace to avoid any conflict with SAP and other namespaces.

The extractor framework regularly refreshes the data through background jobs. Database security policies are then applied by Solution Manager against the CCDB to identify vulnerabilities and security-related events in the platform. The data is also monitored by the MAI which triggers alerts and notifications for critical risks. The results are replicated to an internal Business Warehouse (BW) in Solution Manager.

In next month’s article, we will discuss how you can use Service Level Reporting and BusinessObjects to create detailed and user-freindly reports to convey the results of database security monitoring with SAP Solution Manager.