Maksim Kabakou - Fotolia
Security Think Tank: Deploy multiple defence layers to protect data-rich applications
What should organisations be doing to address application layer attacks and reduce the likelihood of a breach through this type of attack?
The first step any organisation needs to take to protect itself against an application layer attack is to classify the data handled by its applications.
This should then flag the ones that have data that need to be protected. (Corporate enterprise resource planning (ERP) systems and customer-facing web portals, which contain information that is commercially sensitive or personally identifiable, for example.)
A data model of this nature shows an organisation the importance and sensitivity of the information it holds and for what reason. From there, it can take a proactive approach to securing it.
Data with a relatively low value (such as standalone names or email addresses) may not warrant significant investment in security counter-measures while, where the data is particularly sensitive (recipes of products, component lists or personal employee details), a more robust level of security is clearly required.
To get the security approach right-sized, it is vital that risk is at the heart of this evaluation. This decision may be quite simple; data is either sensitive or not sensitive.
However, if there are degrees of sensitivity, it’s important not to be too granular in the categorisation, as this can result in overly complex tiers of security that are not practical to work with in the business environment.
Four levels of data sensitivity should be adequate: public; restricted (internal use only); confidential (limited internal use internal); and classified (need to know only).
The need for multiple layers of defence
Once the classification exercise has been completed, the security approach should become clearer and the actual solutions can be implemented. At this point, there is no single right answer, but it is generally accepted that multiple layers of security should be applied.
It is not enough to place sole reliance on any one security counter-measure. For example, a simple firewall is not sufficient to stop external threats, as many of these connections may be required for integrated supply chain or direct sales to customers.
More proactive monitoring may be required to sort desired network traffic from the suspicious. Here, a traditional Siem (security information and event management) tool may be applicable as it could add a further controlling mechanism that justifies firewalls to be relaxed.
However, Siem tools may identify a breach, such as a system server being compromised, but they may not be able to determine the impact it has had on that particular application layer. Which records were accessed; customers, employees or suppliers? This information is determined through tracing the activities performed in the application and getting a full picture of the vulnerability.
For example, IBM’s QRadar can detect threats to a server, but still needs complimentary products to identify the significance of the threat. These might include SAP Enterprise Threat Detection (ETD), Security Bridge from ABAP-Experts or similar SAP monitoring via Solution Manager, or the internal SAP central monitoring console, CCMS, to identify which records may have been compromised.
The indirect attack
Internal threats and the impact of social engineering also need to be factored in. Rather than breaching particular applications directly, attackers may choose to target them via someone in the organisation that is already authorised.
Tactics include emails from the address of the bona fide individual requesting nefarious actions to be performed, or in an attempt to infect IT assets with malware that would introduce a vulnerability the attacker could exploit.
Prevention
Again, a multi-layered security approach is far more appropriate in dealing with this type of threat. This requires a range of activities, such as server hardening, access triggered malware and virus scanning, and education of individuals on phishing and basic cyber security vigilance.
The exact approach needs to be varied according to the categorisation of the data held in the application as referenced above.
Preparation
At the same time, even with the preventative and technical security measures in place, it’s also important to be prepared for a breach, and have the appropriate processes and procedures in place to manage it.
The data classification will significantly aid this exercise as the severity and impact of a breach can be seen in the context of the impact to specific data sets. Regulatory requirements may mandate specific actions, for example, to notify supervisory authorities of a breach within a very short timeline (72 hours for GDPR for example).
Read more about application layer security
Even if these types of time limits are not relevant, it is vital the organisation has the appropriate reporting processes documented and that their staff are empowered and encouraged to perform their activities accordingly.
In addition to the breach itself, the reputation of many organisations has been further damaged by the inability to respond to it in a coherent and appropriate manner to the satisfaction of customers, media and shareholders.
In conclusion, as with guarding against any kind of breach, the principles are the same. Organisations need to know what they have that needs protecting and where it lives in the system.
From there, they can implement tactics that aim to prevent an attack as far as is possible, but also acknowledge that a hack is highly likely and prepare accordingly to minimise the impact.
