1

We developers of course try to create the most secure (web) application out there that will not be hacked. While we already know it's impossible to know for certain that your application is secure, we at least do our best effort.

By choosing one of the big cloud platform solutions (Azure, AWS, Google) you at least know they do their best to keep hackers away from your web/database servers.

So, let's pick e-commerce for example: A lot of customers, a lot of personal data stored in one database and a lot of employees that want to "work" with the data.

Let's say Azure/AWS/Google does their job good at security and the developers do their job good at security. That means it actually comes down to your employees working with the data of all the customers.

You know, those employees who use the same password everywhere, ending with their birthday and a ! because some password fields require a special character. Those employees that would click on any link they receive in their inbox.

Most, if not all, web applications allow to export data. "I want to analyse last year's sales", "I want to analyse stock inventory". All valid reasons for employees to get your data in Excel and play around with the data.

Now what I am wondering, how do small to large businesses deal with security?

In theory, a employee could export all customer data, have it stored on their personal computer, the personal computer gets stolen and 5 days later an awesome database pops up online containing all your users information. Or these days it is not that uncommon for small and big businesses being hacked, so one of the employees could be the target where they are able to hack and get the data from their personal computer.

Do you:

  • Limit the employee in how much data it can export?
  • Somehow allow or deny access to exporting certain fields?
  • Enforce to always upload to a cloud storage like Microsoft OneDrive and educate the user not downloading it?
  • Use Active Directory while employees use their personal computers?
  • No export at all and provide dashboard graphs on-request?

What else?

||improve this question
  • 3
    Enforce full disk encryption will help on the case of a stolen computer. I worked for a large corporation once, and full disk encryption were mandatory. – ThoriumBR Jan 18 '19 at 17:38
  • I don't understand why an employee would need access to all the data, including the customers' passwords (hashes). If an employee, without a good reason, works on data that contains emails and password hashes, then that's a weakness. Threats exist that can target that data, so it's actually a vulnerability. You fix it by not letting the employees use that data. I don't know what you could do, it depends on your specific needs. As an example, you could strip off emails and password hashes from the database dump, before giving it to the employees for their job. – reed Jan 20 '19 at 23:41
  • @reed No I am not talking about those fields like pasword hashes. E-mail adresses: yes those would be included in most queries. – CularBytes Jan 21 '19 at 18:14
  • @CularBytes, I'm not sure what kind of confidential data you are referring to, and I'm not sure if in your question "user" and "employee" refer to the same person (I assumed so). You might want to add some more info in your question. – reed Jan 21 '19 at 18:19
  • Ok, now it's clear. The problem seems to be that employees follow bad security practices. You then need a security policy and a way to enforce it. In practice, among lots of other things, this translates to not letting your employees use bad passwords or click insecure links. You need a way to check if they are following this advice, and if they are not... kick them in the groin. – reed Jan 21 '19 at 18:44
3

The first questions to ask here are IMHO:

  • who is the owner of the data?
  • what is the responsability of each part?

For the first question the answer is the client not you. So if they want to publish their data on their facebook page, it is their problem, not yours. And as the owner of the data, they must be able to get it from you at any time, because they must be able to stop working with you and make business with someone else (not nice, but they can).

Your reponsability is to secure the data when it is holded by your application, and on the way between the client and the application. So you must make sure that you address the risks and threats that the client consideres important. In your example, choosing a big cloud platform is certainly a good choice for Availability, but did you considere Confidentiality? Can you say how many admins will be able to access the client data, and do you know whether it matters for your client? You say that you will do your best efforts to secure the application, but have you considered a third party security audit, depending on how much the client sees the security as important.

As an IT professionnal, you must also give advices to the client for all the processes where you are involved. Have you specified with the client the access levels if different persons can access the data, and the risks associated with each level? As you speak of poor passwords, have you spent some time to explain the importance of good passwords and have you proposed to pass automatic guess tools (John the Ripper for example) to control the weakness of passwords? If it matters, can you application log who retrieved what to later analyze the causes of a data leak?

IMHO, that is what you should feel concerned with, not what the client wants to do with their own data, beyond giving advices to them.

||improve this answer
  • Thanks for the great answer. In this example I am more talking about employees working with customer data. "Let's pick e-commerce for example". So what individual customers do with their data is out of my concerns. For the employees as being the client: it is not really "their" data, hence this question. Your tips regarding poor passwords and export logging to analyze later are both great points. Data access is mostly there, but mostly every role within a company requires basic customer data, that in relation with other data tables they can access can still expose a great amount of thread. – CularBytes Jan 21 '19 at 18:22
2

Multiple Questions to answer and this is pretty broad...

First, we have multiple layers of "stack" here. Are we talking about direct DB access? What application is calling this data? You might have splunk pulling this info but not allow the middleware/web layer to call data or vice versa.

Second there is access control. Who is accessing the data. Who includes "what programs" also.

Third we have compliance. Does SOX, Hippa, or PCI force regulations on the data.

Fourth we employee and endpoint security. What are the phishing policies, what is the endpoint security (Encryption, remote wipe, lockout).

Fifth we have Tracking: can you tell who accessed the data? Do alarms fire for failed attempts?

...So all this to say that we can't generalize this to a simple answer. Also what works for one data type in one architecture won't work for another data type in another architecture.

There are many places to start, but try OWASP. Here is a sub page to get started on: https://www.owasp.org/index.php/Category:Principle

||improve this answer
  • Thanks for pointing out some really good questions that starts thinking more specific about what data should be "more" protected and what data is less important to look at. – CularBytes Jan 21 '19 at 18:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.