SAP Security Solutions Archives - Page 9 of 10

7 Reasons You Should Upgrade to SolMan 7.2

Layer Seven on August 2, 2016

SAP Solution Manager (SolMan) is the epicenter of SAP implementations and the standard for monitoring and maintaining SAP landscapes. The general availability of release 7.2 in August is expected to deliver major advances in seven specific areas.

The first is support for managing the implementation lifecycle of HANA and S/4HANA. SolMan 7.2 is optimized to not only manage HANA systems but also run directly on HANA. Licenses for HANA are bundled with SAP maintenance contracts and are therefore effectively free for SolMan 7.2.

The second is support for hybrid systems. SolMan 7.1 SP13 or lower is directed primarily at ABAP and Java systems. However, SolMan 7.2 will extend support for monitoring both cloud and on-premise environments including SuccessFactors.

The third is an improved user experience through SAP Fiori. The Fiori launchpad provides a simple and graphical interface and replaces the work centers available in release 7.1. Dashboards have been migrated from Adobe Flash to the SAPUI5 (HTML5). Since HTML5 can be rendered on any device, SolMan no longer needs Android and iOS apps to support mobile users. The Fiori Launchpad enables users to personalize their screens to include access to other applications (see below).

The fourth is a wider array of application and cross-application dashboards for monitoring metrics such as system security, changes, events, incidents, availability and performance. Customers can also leverage custom dashboards using predefined templates available from Focused Insights. This includes dashboards for monitoring not just technical but business metrics. Focused Insights include over 800 best practices KPIs that can be deployed in minutes without programming.

The fifth is an enhanced Custom Code Management application to enable customers to optimize the quality, performance and security of custom developments. This includes governance models to identify custom code in system landscapes and tools such as UPL and SCMON to track the usage of custom code. Usage data can be used to decommission idle code to lower the attack surface for custom developments and reduce the scope of testing during system upgrades or enhancements.

The sixth is tighter integration between the Test Suite and solution documentation, enabling customers to focus testing on business processes impacted by proposed changes. This is performed using Business Process Change Analyzer (BPCA). BPCA leverages the inventory of business processes in solution documentation and Technical Bills of Materials (T-BOMs) for executables within processes.

SolMan 7.2 enables users to record and replay test scripts to automate testing using Component-Based Test Automation (CBTA). These and other applications for creating and maintaining test plans, scripts, and results including defects are accessed through the Test group in the SAP Fiori Launchpad.

The seventh and final reason for upgrading to SolMan 7.2 is that SAP cannot extend the deadline for ending maintenance for release 7.1 beyond December 31, 2017. Customers have a relatively short window to upgrade to release 7.2. The Monitoring and Alerting Infrastructure (MAI) is mandatory for all operations in SolMan 7.2. Therefore, MAI must be enabled in SolMan 7.1 before any upgrade. A stack split is performed during the upgrade procedure. Database migration to SAP HANA can also be performed during the upgrade. Detailed information is available in Notes 2161244, 2045230 and 2045342.

To discuss how Layer Seven Security can support your Solution Manager 7.2 implementation or upgrade projects, contact us here.

Three Reasons You Should Budget for SAP Breach Costs

Layer Seven on June 28, 2016

The average cost of a data breach has now surpassed $4 million. This is according to the latest study from the Ponemon Institute issued earlier this month. The study surveyed 383 organizations in 12 countries. It revealed that not only are data breach costs increasingly across the board, the probability that organizations will suffer a breach impacting 10,000 or more records is 25 percent.

The global results mask significant differences between countries and industries. For example, average data breach costs are highest in the U.S ($7M) and sectors such as healthcare, education and financial services. However, regardless of country or industry, the majority of breaches (48%) are caused by cyber attacks rather than human error or system glitches.

The results of the Ponemon study are contested by the report Beneath the Surface of a Cyberattack from Deloitte Advisory. According to the report, actual costs are far higher than indicated by the Ponemon study which focuses upon measuring direct and tangible costs for breach notification, forensic investigations, legal fees, public relations, regulatory fines and other areas. Deloitte estimate that such costs account for less than 5% of the total business impact of data breaches. The strategic impact of breaches in terms of increased insurance premiums, loss of intellectual property, reputational harm and other hidden costs is far higher than the direct impact. This is illustrated by a breach of patient records experienced by a healthcare company cited in the report. Only 3.5% of the $1.6 billion lost by the company as a result of the breach was associated with direct costs.

Both of the studies echo the results of an earlier report from the Ponemon Institute that placed the average cost of data breaches impacting SAP systems at $4.5M. The report also revealed that 65% of companies had experienced one or more SAP breach within the last 2 years. The significant impact of data breaches and the likelihood that organisations will experience a breach if they haven’t already done so suggests that breach costs should be planned and budgeted. However, aside from region, sector and other factors, there are three reasons that could negatively impact the extent your organization budgets for SAP breach costs. The reasons are outlined below.

1. You do not effectively identify, prioritize and apply security patches for SAP systems

The majority of exploits for SAP systems do not target zero-day vulnerabilities. Most exploits focus upon long-standing and well-known vulnerabilities that can be removed by regularly upgrading SAP systems and applying Security Notes provided by SAP. A case in point is the invoker servlet vulnerability addressed by the recent alert issued by US-CERT. This vulnerability was disclosed in 2010 and addressed by several Notes issued by SAP in the same year.

2. You do not effectively manage vulnerabilities in SAP systems

SAP systems can present a wide attack surface to attackers if they are poorly configured and monitored. A comprehensive vulnerability management program for SAP systems should include continuously monitoring and removing vulnerabilities in areas such as remote function calls, gateway servers, message servers, client-server and server-to-server communication, password policies, session management, audit settings, ICF services, UME settings, Java services and user privileges.

3. You do not effectively discover and respond to malicious events in SAP systems

SAP systems include a wide array of logs that should be continually monitored for indicators of a potential attack. This includes events such as logons or attempted logons with standard users, changes to RFC destinations, ICF services or global settings, trusted system logons, RFC callbacks, path traversals and suspected XSRF attacks. Alerts for such events should be triggered and automatically transmitted to incident response teams to ensure attacks are blocked and contained.

Customers that implement strong patch, vulnerability and threat management programs for SAP systems can justifiably budget far less for SAP breach costs that those that do not by reducing both the likelihood and impact of a potential breach. In fact, they may be able to remove the need to budget for breach costs altogether and rely upon on cyber insurance by satisfying the due diligence requirements of cyber insurance policies.

Customers that haven’t Implemented patch, vulnerability and threat management capabilities can address the gap by leveraging standard tools available in SAP Solution Manager without licencing third party software. This includes System Recommendations for patch management, Configuration Validation for vulnerability management and E2E Alerting for threat management. Layer Seven Security empower customers to unlock the capabilities of SAP Solution Manager for automated vulnerability scanning and security alerting. To learn more, contact Layer Seven Security.

Security in SAP HANA

Layer Seven on May 30, 2016

SAP HANA is now deployed by over 7,500 organizations worldwide. While this represents only a fraction of the 300,000 companies that use SAP software globally, adoption is growing rapidly, doubling in 2015 alone. As expected, the introduction of SAP Business Suite 4 SAP HANA (S/4HANA) has accelerated this growth by widening the use-case for SAP HANA from analytics to transactional processing for core business processes.

While the performance and administrative benefits of SAP HANA are clear-cut, the benefits for security are more questionable. Unlike conventional persistent databases, HANA does not provide any native capability for label-based access control, data discovery and classification, data redaction and masking, or database firewalls. HANA also presents an architectural challenge for security engineers since some implementation scenarios integrate application and database layers that are traditionally hosted in separate physical or virtual servers.

SAP has addressed some of these concerns in later releases of HANA. SPS 12 includes features to isolate databases in multi-tenant environments to prevent cross-database attacks. It also includes more advanced logging capabilities to support multiple log formats and fine-grained audit policies. This is discussed in the newly updated whitepaper Security in SAP HANA, available in the resources section. The whitepaper provides a framework for securing HANA systems including network security, authentication and authorization, encryption for data in transit and at rest, and OS-level security for SUSE Linux Enterprise (SLES) and Red Hat Enterprise Linux (RHEL).

HANA vulnerabilities such as potential misconfigurations in database parameters or users with special privileges should be monitored using SAP Solution Manager (SolMan). In common with other SAP systems, HANA is connected to and monitored by SolMan. Security-relevant data is extracted by agents from HANA and transmitted to SolMan for analysis. SolMan analyzes the data using rulesets to identify potential vulnerabilities that could be exploited by attackers. The results are accessible through BW or BI including Lumira and Crystal Reports.

Rulesets benchmarked against best practices and SAP recommendations can be licensed from Layer Seven Security and imported directly into your Solution Manager platforms. To learn more, contact us.

US-CERT Issues Alert for SAP Invoker Servlet Vulnerability

Layer Seven on May 12, 2016

US-CERT published an alert yesterday to warn SAP customers of the dangers posed by the invoker servlet vulnerability in AS Java systems. According to the alert, there is evidence to suggest that SAP systems at 36 organizations have been exploited by the vulnerability. The organizations are based in the United States, United Kingdom, Germany, China, India, Japan, and South Korea, and operate in industries that include oil & gas, telecommunications, utilities, retail, automotive and the pubic sector.

The invoker servlet vulnerability arises when servlets can be called directly either by servlet name or by fully-qualified class name. This can be exploited to bypass authentication and authorization rules defined in the web.xml files of Java applications. In the cases referenced by the US-CERT alert, attackers appeared to have exploited the invoker servlet to call a Java component that enabled them to execute OS commands and create user accounts in SAP systems.

The vulnerability was patched by SAP in 2010. SAP also modified the default configuration of AS Java to disable the invoker servlet in versions 7.20 and later. Corrections were provided in Notes 1445998 and 1467771. The evidence of the active exploitation of the invoker servlet vulnerability five years after the underlying flaw was patched by SAP demonstrates that the greatest risk posed to SAP systems is the exploit of known weaknesses rather than so-called zero-day vulnerabilities.

The invoker servlet should be disabled at a global level by setting the EnableInvokerServletGlobally key to false. The key is located in the global properties of each J2EE instance. You can follow the three steps below to discover systems in your landscape vulnerable to the exploit using SAP Solution Manager.

1. Create a target system in Configuration Validation to check the value of the key for all systems using the servlet_jsp store. See below.

2. Edit the target system by removing all parameters in the servlet_jsp store except EnableInvokerServletGlobally. Set the value for the key to true and maintain the weight/ info. See below.

3. Run the weighted validation report for all Java systems and review the results of systems with the EnableInvokerServletGlobally set to true. See below.

The invoker servlet vulnerability is one of the 500+ checks performed by security rulesets provided by Layer Seven for ABAP, Java, HANA, and database systems. The rulesets can be imported into your Solution Manager systems in seconds to perform daily automated scans for vulnerabilities in SAP systems. To learn more, contact Layer Seven Security.

How to Visualize Cyber Security Risks in Your Systems with SAP Lumira

Layer Seven on April 28, 2016

SAP Lumira can be used to access, visualize and explore data of any size from virtually any source. It enables users to build and share powerful interactive data visualizations using a simple user-friendly interface. Since Lumira can acquire data and enable users to create customized reports through self-service, it removes the need for programming, scripting and any other form of development.

This article demonstrates how you can use Lumira to visualize security vulnerabilities in your SAP systems and overcome limitations with standard Business Warehouse (BW) reports. The demonstration is based on the Standard Edition of Lumira, available at the SAP Store. This edition will operate with minimal hardware requirements from any system with a Windows 7 or higher operating system.

After Lumira is installed, you will need to add the BW data connector using the Extension Manager since the data source is underlying BW reports in Solution Manager (SolMan). The reports store the results of automated security reviews performed by SolMan. The next step is to set the connection to the BW server in SolMan under Network in the Preferences section. This includes the server URL, hostname, instance and user credentials required for the connection.

Once the connection is established, you can define the variables including reference systems, comparison systems, stores, items and fields. This covers the security policies setup in SolMan, the systems that are mapped for monitoring, and the containers that store the results of the security reviews. We recommend creating a separate Lumira report for each security policy based on different system types (ABAP, Java, HANA, etc.).

You can begin building your visualization and exploring security vulnerabilities as soon as the data is acquired by Lumira. In the report below, we have created charts and tables that convey security vulnerabilities discovered using SolMan by area, system and risk level.

The results can be filtered by any of these elements. The tables provide details of each finding including the objectives of every check, recommendations to remove vulnerabilities, links to relevant SAP Security Notes, and information available at the SAP Help Portal. The reports can be exported to PDF, CSV or Excel. They can also be shared via URLs with users or groups defined in Lumira.

SAP Lumira can be used to visualize not only security vulnerabilities discovered by Solution Manager but also unapplied Security Notes in SAP systems. See below.

To learn more or to discuss how we can assist your organization leverage the full capabilities of SAP Lumira for dynamic, cost-effective and real-time security monitoring, contact Layer Seven Security.

Managing Security with SAP Solution Manager

Layer Seven on January 14, 2016

SAP Solution Manager is the second most widely deployed SAP product after ECC. In other words, there are more installations of SolMan in the world than there are for products such as BI, PI, CRM and SRM. This isn’t surprising when you take into account that SolMan is for IT what ECC is for business: it drives the entire system lifecycle including design, deployment and maintenance. It provides a centralized platform for monitoring system operations, managing changes, provisioning users, and a score of other core IT services. Yet, despite it’s versatility and widespread deployment, most organizations fall short of leveraging the full potential of SolMan. This is especially the case for system security.

Other than central user administration, earlywatch alerts, and system recommendations, most SAP customers are in the dark when it comes to other tools in SolMan that could be used to further security. This includes tools to manage and secure custom code (Clone Finder, Coverage Analyzer), identify security risks (SOS), and validate compliance using customer-specific security policies (Configuration Validation). The SAP paper Managing Security with SAP Solution Manager is intended to bridge this gap by informing customers how to realize the potential of SolMan for security. According to SAP, SolMan’s deep connectivity into systems, it’s central position in each landscape, and its link to the SAP extranet provides the ideal platform for defining, implementing and sustaining secure system landscapes. The paper can be downloaded directly from SAP using this link.

What’s New in the SAP Cybersecurity Framework 3.0

Layer Seven on January 14, 2016

Released earlier this month, the third version of the SAP Cybersecurity Framework includes important changes in the areas of transport layer security, logging and monitoring, and vulnerability management. It also discusses the most significant hack against SAP systems to date: the devastating data breach suffered by U.S Investigation Services (USIS). USIS performed background checks on prospective federal employees for the Office of Personnel Management (OPM) and other government agencies before it’s contracts were severed after the announcement of the breach in 2015.

The breach is estimated to have impacted the personal information of up to 20 million individuals. According to the findings of an internal forensic investigation, attackers were able to breach systems at USIS by exploiting an undisclosed vulnerability in a connected SAP ERP system sometime in 2013. The attack went unnoticed by intrusion detection and other network-level monitoring devices. The specific vulnerability exploited by the attackers has been the subject of widespread speculation by security researchers. Some have argued that the breach was caused by a brute-force password attack. Others have pointed towards RFC exploits or unapplied security patches. The source of the breach could have been any one of these or a combination of other vulnerabilities. The wide attack surface presented by SAP systems makes it impossible to pinpoint the root cause without access to the log data. Regardless, the breach demonstrated the destruction that can be wrought by successful attacks against vulnerable SAP systems. The contracts lost by USIS as a direct result of the attack were valued at $3 billion. The organization laid off 2500 workers and filed for bankruptcy shortly after the public announcement of the breach.

For transport layer security, the framework has been updated in line with RFC 7568 issued by the Internet Engineering Task Force (IETF) for deprecating Secure Sockets Layer Version 3 (SSL v3). SSL was the standard protocol for securing Web-based communication between clients and servers. Support for SSL has been gradually waning as a result of the growing awareness of weaknesses in its encryption scheme and key exchange mechanism. The POODLE vulnerability proved to be the final straw since it could be exploited to break encrypted SSL sessions and access sensitive data passed within such sessions including cookies, passwords and tokens.

The new version of the Framework includes an improved section on Read Access Logging (RAL). RAL should be configured to log access and changes by unauthorized users for sensitive data fields in SAP systems. This includes fields for banking, credit card and salary data. Exclusion lists can be maintained to rule out logging for authorized users. Together with the updated framework, you can also refer to an earlier Layer Seven article on protecting sensitive data in SAP systems using RAL for more information.

Lastly, much of the technical jargon related to Configuration Validation (ConVal) in earlier versions has been removed to focus on the core use-case for ConVal. ConVal is a powerful vulnerability management framework included in SAP Solution Manager that is recommended by SAP for managing vulnerabilities in SAP systems.

Since licensing for Solution Manager is included in SAP support and maintenance agreements, ConVal provides the most cost-effective alternative to third party tools.

You can download version 3 of the SAP Cybersecurity Framework in the whitepaper Protecting SAP Systems from Cyber attack from the Resources section.

Get Ready for SAP Solution Manager 7.2: What to Expect

Layer Seven on December 14, 2015

It’s well known that licenses for SAP Solution Manager are included in SAP maintenance and support agreements. However, with the release of version 7.2 next year, SAP will take this a step further by providing free licenses for SAP HANA for use with SolMan 7.2. Customer’s will still have to pay for hardware costs but HW costs have been falling and there is the option for cloud services to avoid hardware costs altogether.

Other improvements in SolMan 7.2 include a streamlined architecture requiring fewer integrations and system resources and delivering faster processing times. Depending upon the implementation scenario, customers will be able to lower SolMan running costs by up to 70 percent.

SolMan will also provide a vastly improved UI based on the Fiori Lauchpad and support access through Apple, Android and Windows mobile devices. Click on the images below to enlarge.

SolMan 7.2 will provide full support for HANA, S/4HANA, Cloud and Hybrid solutions, enabling customers to manage and monitor all SAP on-premise and cloud systems.

For security monitoring, we can expect improved reporting capabilities based on UI5 that do not require embedded BI or Flash, tighter integration between the SolMan frontend and BW Query Designer to support highly customizable reports, upgraded dashboards and alerts, and the ability to not only discover missing Security Notes for systems using SysRec but also identify the business processes impacted by the planned implementation of Notes. The latter will rely on solution documentation maintained directly in SolMan and a much improved Business Process Change Analyzer application that will integrate with Test Management to enable customers to develop, execute and review the results of test cases for planned changes.

SAP will remove maintenance for the current version of Solution Manager at the close 2017. Customers will have around 18 months to upgrade their Solution Manager platforms. The advanced performance and analytical capabilities offered by SAP HANA together with the major enhancements in Solution Manager 7.2 suggest that most customers will opt for early adoption. This will strengthen SolMan’s position as the premier solution for monitoring the security of SAP systems, providing the lowest total cost of ownership, unlimited flexibility and scalability, and unrivalled performance.

Are your System Users Vulnerable to SAP Hacks?

Layer Seven on November 24, 2015

One of the most telling statistics revealed at BlackHat USA earlier this year was the fact that 84 percent of InfoSec professionals regard unmanaged privileged credentials as the biggest cyber security vulnerability within their organizations. For SAP environments, the dangers posed by abusing user accounts with privileged access are well-known and can include shutting down SAP servers to interrupt the availability of services, reading or modifying sensitive information, and performing unauthorized changes to system configurations, programs, users, and other areas. For this reason, privileged access is carefully granted and vigilantly monitored in most systems, especially productive systems. This includes privileges assigned through powerful authorization profiles such as SAP_ALL, SAP_NEW, S_ABAP_ALL and S_A.SYSTEM.

However, countermeasures to prevent abuses of privileged credentials in SAP systems are usually focused upon dialog users since interactive logon is not possible with most other user types. This includes system users that are used for background processing. Therefore, it’s common to find system users with privileged access in productive systems, especially when such users support several cross-system connections and integration scenarios.

The risks posed by system users with privileged credentials should not be overlooked and can be as grave as those posed by dialog users. Attackers are able to modify user types from system to dialog in several ways. The most common method is through the Function Builder used to build, test and manage function modules.

Attackers can access the Function Builder through transaction SE37 in a connecting system to execute the BAPI_USER_CHANGE remote-enabled function module (RFM). This RFM can be used to implement user changes in destination systems. The changes are applied using a privileged system user in the destination system. The credentials for such users are often stored in RFC destinations configured in connecting systems. The relevant RFC destination is entered in the field RFC target sys of the Function Builder (see below). The username of the system user configured for the RFC connection is entered in the USERNAME import parameter. Finally, the values of the LOGONDATA and LOGONDATAX are maintained to specify the dialog user type.

Once executed from the connecting system, BAPI_USER_CHANGE will change the system user to a dialog user type in the destination system through a remote function call. This will enable the attacker to logon to the destination system through methods such as the Remote Logon option in the RFC destination maintained in the connecting system (see below).

Since attackers can bypass the restrictions placed on system users by abusing the privileged credentials provided to such users, it stands to reason that super user privileges should be managed for all user types, not just dialog users. This should include minimizing privileges for technical system and communication users to the minimum required for each scenario. Trace tools such as STAUTHTRACE, STRFCTRACE and STUSOBTRACE can be used to identify the authorization objects required for each user. This should be supported by enabling switchable authorization checks for sensitive function modules such as BAPI_USER_CHANGE, BAPI_USER_CREATE1 and BAPI_USER_PROFILES_ASSIGN, and, in NetWeaver releases 7.4X, enabling Unified Connectivity (UCON) to restrict external access to remote-enabled function modules.

RFC destinations with stored logon credentials can be identified using the config store RFCDES_TYPE_3 in Configuration Validation (ConVal). RFC users with critical profiles such as SAP_ALL can be identified using the store RFCDES_TYPE_3_CHECK. See below.

Monitoring SAP Security Metrics with SolMan Dashboards

Layer Seven on November 18, 2015

SAP Solution Manager (SolMan) includes a complete dashboard framework for visualizing data metrics and KPIs across a wide variety of areas. This includes areas such as availability, performance, service delivery, and crucially, system security. What’s more, the process for enabling and customizing dashboards is relatively quick and simple. This short guide walks through the steps to leverage the SAP-delivered dashboard apps in SolMan for security monitoring.

The first step is creating a link to the dashboard in the SAP Easy Access menu. Once you have logged into SolMan, right click on the Favorites folder and select Add Other Objects.

From the list in the Restrictions screen, choose Web-Dynpro Application.

Enter GENERIC_DASHBOARD_VIEWER in the Web Dynpro Applicat. field of the Web Dynpro Application screen.

Enter Security Dashboard in the description field.

Select HTTPS if applicable.

Within the Parameter table, enter ALIAS in the Name column and CIO_PERSONAL in the Value column. Click Save when complete.

The Security Dashboard link will now appear in your Favorites menu. Double click on the link to launch the dashboard in a browser. You will require the role SAP_SM_DASHBOARDS_DISP to access the dashboard, including the auth object SM_DBSINST.

The second step is configuring security apps in the dashboard. The welcome screen below is displayed the first time you access the dashboard. Select Configure in the top right of the screen and then Add new App.

Select the Cross-Application category. Click on the image below to enlarge.

Select and configure the following apps in sequence: Security Overview, Security Details, and Security List. You can learn more about these dashboard security apps at the SAP Help Portal.

Follow the steps below for each app.

Select one of the specified apps and click OK.

Enter a title for the app in the Header field. In the example below, we have configured the Security List app which displays the compliance status of systems by Software, Configuration, and User areas. The Software group includes checks for the release and support pack level of critical software components, kernel levels, and unapplied Security Notes. The Configuration group includes checks for security-relevant profile parameters, access control filters in operating system files such as sec_info and reg_info, client change settings, Security Audit Log filters, RFC destinations with stored logon credentials, trusted RFC connections, and active Web services. Finally, the Authorization group includes checks for users with critical authorization objects or combinations of auth objects, sensitive transactions, and powerful SAP-delivered profiles such as SAP_ALL. It also includes checks for standard users with default passwords.

The next step is to select the target system. This is the template that contains the baseline security policy used to check the compliance levels of systems in your landscape. You can select default templates such as 0SEC_NEW. However, best practice is to develop custom templates to perform checks for a wider array of vulnerabilities in SAP systems than covered by SAP-delivered defaults. Templates developed by Layer Seven Security, for example, perform over 500 vulnerability checks for ABAP, Java and HANA systems.

Once you have selected the target system, specify the comparison systems that should be monitored using the dashboard security app. In the example below, we’ve chosen to monitor the ABAP stack of the system SMP using the custom template in the virtual target system SEC_ABAP. This is a simplified example. In most cases, multiple systems should be selected for monitoring at the same time against a single target system.

Select Preview to sample the dashboard and then click Apply when done. Perform the configuration steps for the other security apps available in the SolMan dashboard. Save the Dashboard. Once complete, the dashboard should resemble the following:

The final step is to set the Auto Refresh frequency in the drop-down menu positioned in the top right of the dashboard. Once set, the dashboard will refresh as often as every 5 minutes for near real-time security monitoring.