In any good defense strategy, reducing the area the attackers can target is the most basic – and yet most effective – option.
Indeed, this then means that you can focus your efforts on protecting the area left exposed either because it’s a low ground, or simply because you need to leave it open and accessible to be able to operate.
For instance, an online retailer wouldn’t shut down their web presence to reduce the number of attacks they receive on their site, would they? If they do, they will of course be very successful in deterring attackers, but they may be a lot less successful financially…
To decide what attack surface can be reduced, business and process owners but also IT experts must work together. The first set of stakeholders will be able to determine what information is required by operators to perform their tasks, and the second set of colleagues – the IT experts, will be able to determine whether this information left unexposed can be protected.
As per Ponemon Institute’s Cost of Insider Threats: Global Report 2020, out of 4,716 incidents reported, 2,961 “were due to negligent or inadvertent employees or contractor”. With an average cost of $307,111 when incidents involve a negligent employee or contractor, and a frequency of incidents that has tripled since 2016 it can quickly become costly.
And that’s not even counting new legislation and associated potentially heavy fines for non-compliance that make companies responsible for controlling who can access, view, and modify sensitive data internally and for tracking access, not just securing sensitive data.
So, what good is it to have a 30m(*) high wall if people inside the fortress can enter the treasure room where the crown jewels are stored as they please?
In some cases, only providing selected people with access works well, but that’s not scalable and also doesn’t work for all information.
Let’s take customer data: many people within the organization will need to access customer information to be able to provide the relevant goods and services.
For instance:
- Issue a bill and reconcile a payment
- Ship a good that has been purchased to the right address
- Provide customer support and troubleshooting in case there are issues
But does everyone need to access all the customer information – including sensitive data? The answer is no, of course, and this is where reducing the attack surface becomes interesting.
As mentioned, reducing the number of people who can access might not be the best answer as this would prevent colleagues from performing their duties effectively. So, one other option could be creating more and more granular roles to cater for specificities in access rights. And this will work… in the short term!
In the medium to long term, it will most likely lead to a “role explosion” phenomenon where more and more roles are created. Not only does this increase administrative burden in continuously (re)allocating roles to the right people, but also in ongoing maintenance. After some time, you can bet that no-one will even remember what most roles are about and will just create more because they don’t know the exact one they need already exists…
Instead, what about focusing on attribute and context-based access?
What is attribute and context-based access?
This is another layer that is added on top of existing authorization concepts to enable organizations to mask values in sensitive screen fields for refined data access.
By applying data protection obfuscation or masking mechanisms, organizations can restrict who gets to see critical information in transactions and applications – and under what circumstances – without complex authorization setup, system modifications, or custom user interfaces and variants.
In summary, it uses metadata about the user and the data object to determine the access rights therefore enabling dynamic determinations of data access authorizations based on the context.
In addition to being more granular than regular roles, it also enables the context to be taken into account at the time of the transaction.
Let’s take the example of customer support that we had earlier.
In most cases, accessing the customer address, their date of birth, etc. can be a legitimate requirement to ensure that the product has been shipped to the right person, that the person on the line is the legitimate account owner, and so on.
But, in some cases, this information can be very sensitive – especially for exposed people such as people in politics, in the media, etc. Being able to determine that a field is usually accessible by the customer representative but, that for certain categories of customers this is hidden and would require a specific criteria, can be required.
But even for the people who can access this sensitive data, how can one ensure that they are only using it for a legitimate purpose?
This is where the “reveal on demand” concept enters. With this mechanism, the sensitive fields are initially masked, independent of the user’s authorizations, and then only unmasked after the user requests and justifies access, which is recorded for review and audit purposes.
Benefits for all parties!
This approach actually provides benefits for all parties:
- Customer because their sensitive data is protected and only accessed when relevant
- Organization because it reduces the information that can be leaked due to error or malicious intent
- Employee because they haven’t been prevented from performing their tasks, but they have the peace of mind to know that they won’t be questioned in case there is a data leakage. They won’t have to prove their innocence since the field wasn’t displayed by default and, in case it was accessed, the date, time, reason, are well documented.
But have you thought of all channels?
In cybersecurity probably more than in most other areas, consistency is key if you want to be secure. Would you really lock the door if you left your windows open? No, right?
Well, what about masking a field in display mode but not in edit? What about masking in both modes but not in list? And don’t get me started on masking all channels… but not in download or print!
Defining data security actions and authorizations at a data-element or table-field level and have them consistently applied across sensitive mapped fields and supported user interface channels including download, export and printouts will make sure that you don’t leave a major gap open for misuse.
Being flexible and quite light to orchestrate, this approach de facto limits the risk of falling victim to data being stolen, abused or leaked. So why not give it a try?
What about you, how does your company manage access to sensitive data? I look forward to reading your thoughts and comments either on this blog or on Twitter @TFrenehard
(*): Highest maximum historic height of all “Famous city walls” according to Wikipedia. Source: Defensive wall - Wikipedia
- SAP Managed Tags:
2 Comments
| User | Count |
|---|---|
| 6 | |
| 3 | |
| 3 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
