- Some Best Practises about Application Security Monitoring and Network IT Security
From a historical perspective, Security Experts performing Security Monitoring have generally been very focussed on Network and IT Security Monitoring. Very often, companies have a a Security Operating Center (SOC), or the SOC is offered by others as a service. The Application Security Monitoring (ASM) does - from this historical viewpoint - play no or only a minor role for the SOC team. Suspicious activities within applications used by the company and executed by users, who already have access to those application systems, are not necessarily seen as an outside threat (although a user may have been hacked and abused within an application), additionally there is still a knowledge gap regarding Application Security.
As the threats within the application have already reached the network and access to critical corporate data is possible, one might come to the conclusion that such threats are as critical as network/IT threats. The two threat categories may even correlate with each other. A network/IT hack can be a preceding activity for an application hack.
Hence a need for knowledge about application security threats, monitoring and detection within the SOC team is strongly suggested, to be able to have an end-to-end view on any kind of cyber security critical activities.
Finally, how can Security Experts be additionally empowered for the area of application security ? And can the knowledge from both worlds be combined in one SOC?
Here are some Best Practises thoughts:
Standard Operation Procedures (SOPs): SOPs are essential when processing cyber security alerts. They document standardized corporate guidelines for processing the alert. A SOP -however- cannot fully replace a deep or semi-deep knowledge of a particular security topic. Based on SOPs, the Security Expert can start working in the area of Application Security Monitoring and Alerting. When it comes to determining the criticality of an alert or a forensic analysis, e.g. about sequence of activities within an application by a user, knowledge gaps remain when relying only on SOPs.
Conclusion about a Best Practise: SOPs are essential, but additional learning is still needed!
Log Data and Tooling: Simply feeding application (log) data into a standard Security Information and Event Management (SIEM) system, used by the SOC, is not very helpful in understanding or interpreting the data being fed. In fact, the in-depth knowledge is more than necessary, because security use cases must be extracted from raw data, which works, but requires a lot of detailed knowledge about most different application logs, their correlation, and application security as well as a lot of time to model these use cases.
Simply speaking, another tool that includes application log interpretation out of the box, use cases, and appropriate alerting makes sense. It can do the pre-evaluation and send the pre-assessed data (alerts due to suspicious activities within an application) to the SIEM system. The integration of an ASM can be thought of as an Anti Virus (AV) system. The AV does the work, finds patterns and code sequences, raises alerts when a virus is found on a machine, and additionally quarantines the vulnerable file or executable. The alerts and actions are forwarded to a SIEM, which then aggregates the information into an overall security status.
Conclusion about a Best Practise: Think about using an ASM to integrate with a SIEM!
How to work together:
Security is a joined effort of the different groups in an organization, e.g. the Network and IT Security organization, or the Application Administration organization. If they do not work together (sufficiently), there is no overall picture of security from a knowledge point of view. If assumed that the SOC team is mainly responsible security aspects of the company as a whole , the SOC team must learn primarily from the Application Administration. This can certainly be done in a different way:
Conclusion about a Best Practise: A joint, intensive, and trustful collaboration within a company to cover security in all layers, is needed.
Iterative approaches: Very often and typical, companies iteratively integrate some of the Application Security Use cases iteratively into the SOC team. This often appears to be the most feasible approach, as the efforts can be managed by both the SOC team and the Application Administration and Security team. The costs of Security is not even increased. This can be done by using an AMS tool and integrating use cases into the SIEM system, but also by creating the use cases directly in the SIEM tool. It is a question of effort and time how to accomplish this, and of the type of collaboration (see above). However, the general issue with such iterative approaches is that the integration of only a few Application Security Uses cases into the SIEM product and the corresponding creation of SOPs takes a long time, which is rather years than months. And often, the collaboration ends after these few use cases are integrated and there is no (major) progress. This might be due to the high effort to explain every single single Application Security use case, and background knowledge was not (sufficiently) built up due to time and budget constraints. The notion that 'the Security journey never ends' is well known, but in reality it does end due to these time and budget restrictions.
Conclusion about a Good Practise: An iterative approach as described (i.e. without any additional resources that do the work) is not suggested, or maybe only be suitable as a starting point. After a certain period of time, it must result into a collaborative effort that has where dedicated people working on it.
Let others do the work (Shared Service Centres for Managed Security Services): There are many offers that can be used to outsource the various security issues to a third-party company. There are some advantages doing that:
However, logically, these services run into the void if there were no counterpart to a detection by the security service, who is, for example, responsible and knowledgeable for the implementation of a countermeasure.
Conclusion about a Best Practise: Take Managed Security Services into account for the above reasons, but make sure that the knowledge of Security Experts stays always within the company and that there is a well-defined collaboration mode.
Overall Conclusion:
Security is a journey that never ends. To start or keep the journey going, especially to get a comprehensive security approach, Security Experts need to have or acquire knowledge about network and application security (and others), which comes with (more) additional effort. Low-effort approaches fail quite often. Appropriate IT and application-level security monitoring tools are useful to facilitate startup or maintenance of operations, and consideration can be given to using managed security services tailored to the needs of the business.
From a historical perspective, Security Experts performing Security Monitoring have generally been very focussed on Network and IT Security Monitoring. Very often, companies have a a Security Operating Center (SOC), or the SOC is offered by others as a service. The Application Security Monitoring (ASM) does - from this historical viewpoint - play no or only a minor role for the SOC team. Suspicious activities within applications used by the company and executed by users, who already have access to those application systems, are not necessarily seen as an outside threat (although a user may have been hacked and abused within an application), additionally there is still a knowledge gap regarding Application Security.
As the threats within the application have already reached the network and access to critical corporate data is possible, one might come to the conclusion that such threats are as critical as network/IT threats. The two threat categories may even correlate with each other. A network/IT hack can be a preceding activity for an application hack.
Hence a need for knowledge about application security threats, monitoring and detection within the SOC team is strongly suggested, to be able to have an end-to-end view on any kind of cyber security critical activities.
Finally, how can Security Experts be additionally empowered for the area of application security ? And can the knowledge from both worlds be combined in one SOC?
Here are some Best Practises thoughts:
Standard Operation Procedures (SOPs): SOPs are essential when processing cyber security alerts. They document standardized corporate guidelines for processing the alert. A SOP -however- cannot fully replace a deep or semi-deep knowledge of a particular security topic. Based on SOPs, the Security Expert can start working in the area of Application Security Monitoring and Alerting. When it comes to determining the criticality of an alert or a forensic analysis, e.g. about sequence of activities within an application by a user, knowledge gaps remain when relying only on SOPs.
Conclusion about a Best Practise: SOPs are essential, but additional learning is still needed!
Log Data and Tooling: Simply feeding application (log) data into a standard Security Information and Event Management (SIEM) system, used by the SOC, is not very helpful in understanding or interpreting the data being fed. In fact, the in-depth knowledge is more than necessary, because security use cases must be extracted from raw data, which works, but requires a lot of detailed knowledge about most different application logs, their correlation, and application security as well as a lot of time to model these use cases.
Log from an SAP application. Is it critical from a security point of view?
Simply speaking, another tool that includes application log interpretation out of the box, use cases, and appropriate alerting makes sense. It can do the pre-evaluation and send the pre-assessed data (alerts due to suspicious activities within an application) to the SIEM system. The integration of an ASM can be thought of as an Anti Virus (AV) system. The AV does the work, finds patterns and code sequences, raises alerts when a virus is found on a machine, and additionally quarantines the vulnerable file or executable. The alerts and actions are forwarded to a SIEM, which then aggregates the information into an overall security status.
Conclusion about a Best Practise: Think about using an ASM to integrate with a SIEM!
How to work together:
Security is a joined effort of the different groups in an organization, e.g. the Network and IT Security organization, or the Application Administration organization. If they do not work together (sufficiently), there is no overall picture of security from a knowledge point of view. If assumed that the SOC team is mainly responsible security aspects of the company as a whole , the SOC team must learn primarily from the Application Administration. This can certainly be done in a different way:
- Conduct (not only some, but) an extensive knowledge exchange focused on the Application to SOC direction. The goal for the SOC team is to be able to partially understand the Application Security needs, attack vectors and use cases. Further communication exchange needs to be done on a very regular basis to make continuous progress.
- Hire Application Security Experts on the SOC team, and with a one-time effort, aggregate all (i.e. as much as possible) security knowledge within the SOC team.
- In both cases boundaries have to be overcome. These are linguistic barriers (SOC team and Application Administration speak completely different messages), and in some cases also the necessary redefinition of competencies, and the dismantling of prejudices (in the worst case).
Conclusion about a Best Practise: A joint, intensive, and trustful collaboration within a company to cover security in all layers, is needed.
Iterative approaches: Very often and typical, companies iteratively integrate some of the Application Security Use cases iteratively into the SOC team. This often appears to be the most feasible approach, as the efforts can be managed by both the SOC team and the Application Administration and Security team. The costs of Security is not even increased. This can be done by using an AMS tool and integrating use cases into the SIEM system, but also by creating the use cases directly in the SIEM tool. It is a question of effort and time how to accomplish this, and of the type of collaboration (see above). However, the general issue with such iterative approaches is that the integration of only a few Application Security Uses cases into the SIEM product and the corresponding creation of SOPs takes a long time, which is rather years than months. And often, the collaboration ends after these few use cases are integrated and there is no (major) progress. This might be due to the high effort to explain every single single Application Security use case, and background knowledge was not (sufficiently) built up due to time and budget constraints. The notion that 'the Security journey never ends' is well known, but in reality it does end due to these time and budget restrictions.
It requires a lot of drops to fill the lake
Conclusion about a Good Practise: An iterative approach as described (i.e. without any additional resources that do the work) is not suggested, or maybe only be suitable as a starting point. After a certain period of time, it must result into a collaborative effort that has where dedicated people working on it.
Let others do the work (Shared Service Centres for Managed Security Services): There are many offers that can be used to outsource the various security issues to a third-party company. There are some advantages doing that:
- Especially when there is no/too little knowledge and/or personnel available on security topics of any kind, experts can help out and really drive a previously orphaned topic
- The speed with which a topic is started/covered is much higher compared with own investments in personnel
- The additional services can be tailored to the company needs
- From a price perspective, services in a shared services model appear to be affordable, and may not be more expensive than investment into in-house staff/personnel
However, logically, these services run into the void if there were no counterpart to a detection by the security service, who is, for example, responsible and knowledgeable for the implementation of a countermeasure.
Conclusion about a Best Practise: Take Managed Security Services into account for the above reasons, but make sure that the knowledge of Security Experts stays always within the company and that there is a well-defined collaboration mode.
Overall Conclusion:
Security is a journey that never ends. To start or keep the journey going, especially to get a comprehensive security approach, Security Experts need to have or acquire knowledge about network and application security (and others), which comes with (more) additional effort. Low-effort approaches fail quite often. Appropriate IT and application-level security monitoring tools are useful to facilitate startup or maintenance of operations, and consideration can be given to using managed security services tailored to the needs of the business.
- SAP Managed Tags:
