As of release 2.4, SAP Enterprise Threat Detection seamlessly supports the use of SAP HANA native storage extension (NSE) for the warm storage of log data. SAP HANA native storage extension is the built-in warm data store in SAP HANA that lets you manage less-frequently accessed data without fully loading it into memory. It was introduced to SAP HANA 2.0 with SPS4.
We recommend to use SAP Enterprise Threat Detection with SAP HANA native storage extension instead of SAP HANA dynamic tiering as warm data store.
When using NSE as warm data store, you can configure retention times for warm storage via the Settings app of SAP Enterprise Threat Detection.
As of release 2.4 the Settings app shows the retention periods for warm data and hot data storage. The total retention time is the sum of the retention periods for hot storage and warm storage. Both hot and warm storage are online storages, that means that data residing in hot and warm storages can be accessed from all apps in SAP Enterprise Threat Detection.
Using NSE, you can expand the warm data capacity of the SAP HANA database to approximately four times the size of the hot data in memory. For example, if you store the log events of one week in hot storage, you can store the log events of up to four weeks in warm storage.
For more information, see the following blog post: SAP HANA Native Storage Extension(NSE) – Increase HANA Data Capacity With Warm Storage.
Data in NSE are stored using page-loadable storage. That means that NSE loads only the pages into memory that include data that is relevant to your search. Pages containing data that is not accessed by your query are not loaded from disk.
So, what happens if you access older data residing in NSE from SAP Enterprise Threat Detection apps like Forensic Lab or Log Events? Well, the data is then automatically loaded page by page into HANA hot memory to meet the request criteria of the respective user interface.
What happens when the data in the hot storage reaches the end of its retention period? The data is automatically moved to NSE and can still be accessed.
What happens if the data in the warm storage reaches the end of its retention period? It is automatically removed from NSE. This data can then only be found in the cold storage configured for SAP Enterprise Threat Detection. Keep in mind that the cold storage is an offline storage that cannot be accessed automatically from SAP Enterprise Threat Detection apps. To access the data from SAP Enterprise Threat Detection, it first has to be loaded into HANA. For more information, see the documentation for the Cold Storage Writer of SAP Enterprise Threat Detection.
To allow for real-time alert creation, we recommend to choose a retention period for the log events in hot storage that is at least as long as the longest time range defined for the attack detection patterns. This way you avoid the loading of data from NSE for pattern execution and achieve the best cost-performance trade-off.
Take the following example:
Let's assume the longest time range of standard patterns delivered with SAP Enterprise Threat Detection is 1 week. In this case, it' best to choose a retention time for events in hot storage of at least 1 week. If your customer-specific ad hoc analyses often go back further into the past, you should of course also take this into account when specifying the retention periods for the log events.
Are you wondering whether the support of native storage extension is important to you even if you are already using SAP Enterprise Threat Detection and your systems are already the appropriate size?
Of course it is!
You can configure the retention time for NSE in the Settings app and thus turn part of the previous offline data into online data. You can also reduce the retention time configured for hot storage and increase the retention time for warm storage accordingly. In this way, you can free up part of the hot memory and thereby, for example, reduce the response times of the apps, accelerate pattern execution, or have more free hot memory for memory-intensive ad hoc analyzes.
Now, if you are planning to use SAP Enterprise Threat Detection, then you can now run SAP Enterprise Threat Detection on a smaller sized hardware than it was required for older SAP Enterprise Threat Detection releases and thus save hardware cost. For sizing recommendations, see the Sizing Guide for SAP Enterprise Threat Detection.
For more information about native storage extension for SAP Enterprise Threat Detection, see the information about Event Storage in the implementation guide.
You will also find more information about SAP Enterprise Threat Detection on the community page.
I am looking forward to your feedback.
We recommend to use SAP Enterprise Threat Detection with SAP HANA native storage extension instead of SAP HANA dynamic tiering as warm data store.
When using NSE as warm data store, you can configure retention times for warm storage via the Settings app of SAP Enterprise Threat Detection.
As of release 2.4 the Settings app shows the retention periods for warm data and hot data storage. The total retention time is the sum of the retention periods for hot storage and warm storage. Both hot and warm storage are online storages, that means that data residing in hot and warm storages can be accessed from all apps in SAP Enterprise Threat Detection.
Using NSE, you can expand the warm data capacity of the SAP HANA database to approximately four times the size of the hot data in memory. For example, if you store the log events of one week in hot storage, you can store the log events of up to four weeks in warm storage.
For more information, see the following blog post: SAP HANA Native Storage Extension(NSE) – Increase HANA Data Capacity With Warm Storage.
Data in NSE are stored using page-loadable storage. That means that NSE loads only the pages into memory that include data that is relevant to your search. Pages containing data that is not accessed by your query are not loaded from disk.
So, what happens if you access older data residing in NSE from SAP Enterprise Threat Detection apps like Forensic Lab or Log Events? Well, the data is then automatically loaded page by page into HANA hot memory to meet the request criteria of the respective user interface.
What happens when the data in the hot storage reaches the end of its retention period? The data is automatically moved to NSE and can still be accessed.
What happens if the data in the warm storage reaches the end of its retention period? It is automatically removed from NSE. This data can then only be found in the cold storage configured for SAP Enterprise Threat Detection. Keep in mind that the cold storage is an offline storage that cannot be accessed automatically from SAP Enterprise Threat Detection apps. To access the data from SAP Enterprise Threat Detection, it first has to be loaded into HANA. For more information, see the documentation for the Cold Storage Writer of SAP Enterprise Threat Detection.
To allow for real-time alert creation, we recommend to choose a retention period for the log events in hot storage that is at least as long as the longest time range defined for the attack detection patterns. This way you avoid the loading of data from NSE for pattern execution and achieve the best cost-performance trade-off.
Take the following example:
Let's assume the longest time range of standard patterns delivered with SAP Enterprise Threat Detection is 1 week. In this case, it' best to choose a retention time for events in hot storage of at least 1 week. If your customer-specific ad hoc analyses often go back further into the past, you should of course also take this into account when specifying the retention periods for the log events.
Are you wondering whether the support of native storage extension is important to you even if you are already using SAP Enterprise Threat Detection and your systems are already the appropriate size?
Of course it is!
You can configure the retention time for NSE in the Settings app and thus turn part of the previous offline data into online data. You can also reduce the retention time configured for hot storage and increase the retention time for warm storage accordingly. In this way, you can free up part of the hot memory and thereby, for example, reduce the response times of the apps, accelerate pattern execution, or have more free hot memory for memory-intensive ad hoc analyzes.
Now, if you are planning to use SAP Enterprise Threat Detection, then you can now run SAP Enterprise Threat Detection on a smaller sized hardware than it was required for older SAP Enterprise Threat Detection releases and thus save hardware cost. For sizing recommendations, see the Sizing Guide for SAP Enterprise Threat Detection.
For more information about native storage extension for SAP Enterprise Threat Detection, see the information about Event Storage in the implementation guide.
You will also find more information about SAP Enterprise Threat Detection on the community page.
I am looking forward to your feedback.
- SAP Managed Tags:
