# 9 – Implement a security strategy for logging, testing, and responding to security events
**Do you have a strategic security plan that is supported by the appropriate logging, testing, and documented response methodology?** Having a strategic security plan helps shape the proactive and reactive tasks that must be accomplished to ensure that all security challenges are met successfully. The procedures for logging, detection, and additional protection to help identify and remediate security incidents for SAP on AWS workloads are identical to those detailed in the Well-Architected Framework Security Pillar. Review the best practices regarding detection and incident response within the Security Pillar in addition to the guidance in this section.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/design-principle-9.html)
+ Well-Architected Framework [Security]: [Detection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
+ Well-Architected Framework [Security]: [Incident Response](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html)
# Best Practice 9.1 – Understand your strategy for SAP application and database security event analysis
Without keeping security logs at the appropriate levels of granularity, vital data required for incident response, forensic security analysis, and threat modeling can be lost. SAP security staff must be able to evaluate potential security incidents affecting SAP systems in alignment with your business security requirements. For SAP workloads running on AWS, the AWS services described in the Well-Architected Framework Security Pillar are a helpful starting point in conjunction with the following suggestions.
+ Well-Architected Framework [Security]: [Detection – Configure](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/configure.html)
**Suggestion 9.1.1 – Determine which logs are required to detect security events**
For individual SAP software and supported databases refer to the SAP NetWeaver Guide Finder as well as the SAP NetWeaver Security Guide for what logs might be applicable (for example, [read access logging](https://help.sap.com/viewer/621bb4e3951b4a8ca633ca7ed1c0aba2/LATEST/en-US/631dfbf00a604784b69fc30570bfb69d.html)). In addition, review the SAP advisory on [security logging](https://help.sap.com/viewer/1a93b7a44ac146b5ad9b6fd95c1223cc/LATEST/en-US/182e167819f6405792686e94c177b9eb.html) and related topics surrounding best practices for your development activities.
+ SAP Documentation: [SAP NetWeaver Guide Finder](https://help.sap.com/viewer/nwguidefinder)
+ SAP Documentation: [ABAP Platform Security Guide](https://help.sap.com/viewer/621bb4e3951b4a8ca633ca7ed1c0aba2/LATEST/en-US/4aaf6fd65e233893e10000000a42189c.html)
+ SAP Documentation: [Security Logging](https://help.sap.com/viewer/1a93b7a44ac146b5ad9b6fd95c1223cc/LATEST/en-US/182e167819f6405792686e94c177b9eb.html)
**Suggestion 9.1.2 – Develop mechanisms for storing and analyzing logs**
Having relevant data regarding potential security events is necessary for any secure SAP installation, but it is equally important to store that data securely and have the necessary tools for searching and analyzing the data in an efficient and timely manner. One option within AWS includes using the [CloudWatch Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/monitoring-cloudwatch-agent.html) to store instance logs and SAP application logs relevant to security in an [Amazon CloudWatch log group](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html). Such logs could also be [exported to Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) for holistic log analysis and for integration with [third-party log analytics solutions](https://aws.amazon.com/marketplace/solutions/control-tower/siem).
Refer to the following for help with assembling, combining, and analyzing your SAP on AWS security logs:
+ SAP Lens [Security]: [Suggestion 7.4.4 - Consolidate user and authorization events in a Security Information and Event Management (SIEM) system for analysis](best-practice-7-4.md)
+ SAP on AWS Blog: [Set up observability for SAP HANA databases with Amazon CloudWatch Application Insights](https://aws.amazon.com/blogs/awsforsap/sap-hana-observability-with-amazon-cloudwatch-application-insights/)
+ SAP on AWS Blog: [SAP HANA monitoring: A serverless approach using Amazon CloudWatch](https://aws.amazon.com/blogs/awsforsap/sap-hana-monitoring-a-serverless-approach-using-amazon-cloudwatch/)
+ SAP on AWS Blog: [SAP Monitoring: A serverless approach using Amazon CloudWatch](https://aws.amazon.com/blogs/awsforsap/sap-monitoring-a-serverless-approach-using-amazon-cloudwatch/)
**Suggestion 9.1.3 – Use machine learning to analyse and determine events of importance**
Consider applying pattern recognition, anomaly detection, or both to security logs to assist in determining potential threats and events of importance to your SAP workload. AWS managed services, such as [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) and [Amazon GuardDuty](https://aws.amazon.com/guardduty/), can help, combined with third-party security solutions from the AWS Marketplace.
+ AWS Video: [An Overview of AWS Security Hub CSPM](https://www.youtube.com/watch?v=oBac-GAoZJ8)
+ AWS Documentation: [Getting started with GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html?ref=wellarchitected)
# Best Practice 9.2 – Perform periodic tests for security bugs
As described in the Well-Architected Framework Security Pillar incident response sections on simulations, assembling a runbook and conducting game days are recommended for all workloads, including those for SAP on AWS. This type of periodic testing can identify new attack vectors and vulnerabilities as well as prepare your SAP security resources for a rapid and effective response in the event of a security incident.
Well-Architected Framework [Security]: [Incident Response – Simulation](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/simulate.html)
**Suggestion 9.2.1 – Include SAP applications as targets in addition to standard security and penetration testing**
Probative security testing is an important part of maintaining a secure environment. In addition to conducting standard penetration testing in AWS, make sure to include your SAP solution as an additional potential target for malicious activities. Keep in mind SAP-specific software solutions that often are publicly exposed in your architecture such as SAProuter, Web Dispatcher, Cloud Connector, and SAP Fiori.
+ AWS Documentation: [Penetration Testing](https://aws.amazon.com/security/penetration-testing/)
# Best Practice 9.3 – Have a documented plan for responding to security events
Without a documented plan for addressing a security event involving your SAP applications, the security team’s response may be delayed, less comprehensive, and less effective both in mitigating the event and understanding its cause. Document security response patterns thoroughly for your SAP applications.
**Suggestion 9.3.1 - Prepare for security events by having a documented incident management plan**
This directly aligns with the AWS Well-Architected Framework Security Pillar guidance on incident response preparation. Refer to this documentation and be sure to include your SAP applications accordingly:
+ Well-Architected Framework [Security]: [Incident Response – Prepare](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/prepare.html)