cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Building a Culture for Data Protection

Level 12

DataTiles.jpg

Building a culture that favors protecting data can be challenging. In fact, most of us who love our data spend a huge amount of time standing up for our data when it seems everyone else wants to take the easiest route to getting stuff done. I can hear the pleas from here:

  • We don't have time to deal with SQL injection now. We will get to that later.
  • If we add encryption to this data, our queries will run longer. It will make the database larger, which will also affect performance. We can do that later if we get the performance issues fixed.
  • I don't want to keep typing our these long, complex passwords. They are painful.
  • Multi-factor authentication means I have to keep my phone near me. Plus, it's a pain.
  • Security is the job of the security team. They are a painful bunch of people.

…and so on. What my team members don't seem to understand is that these pain points are supposed to be painful. The locks on my house doors are painful. The keys to my car are painful. The PIN on my credit card is painful. All of these are set up, intentionally, as obstacles to access -- not my access, but unauthorized access. What is it about team members who lock their doors, shred sensitive documents, and keep their collector action figures under glass that don't want to protect the data we steward on behalf of customers? In my experience, these people don't want to protect data because they are measured, compensated, and punished in ways that take away almost all the incentives to do so. Developers and programmers are measured on the speed of delivery. DBAs are measured on uptime and performance. SysAdmins are measured on provisioning resources. And rarely have these roles been measured and rewarded for security and privacy compliance.

To Reward, We Must Measure

How do we fix this? We start rewarding people for data protection activities. To reward people, we need to measure their deliverables.

  • An enterprise-wide security policy and framework that includes specific measures at the data category level
  • Encryption design, starting with the data models
  • Data categorization and modeling
  • Test design that includes security and privacy testing
  • Proactive recognition of security requirements and techniques
  • Data profiling testing that discovers unprotected or under-protected data
  • Data security monitoring and alerting
  • Issue management and reporting

As for the rewards, they need to focus on the early introduction of data protection features and service. This includes reviewing designs and user stories for security requirements.

Then we get to the hard part: I'm of a thought that specific rewards for doing what was expected of me are over the top. But I recognize that this isn't always the best way to motivate positive actions. Besides, as I will get into later in this series, the organizational punishments for not protecting data may be so large that a company will not be able to afford the lack of data protection culture we currently have. Plus, we don't want to have to use a prison time measurement to encourage data protection.

In this series, I'll be discussing data protection actions, why they are important, and how we can be better at data. Until then, I'll love to hear about what, if any, data protection reward (or punishment) systems your organization has in place today.

19 Comments
Level 13

Good Article

MVP
MVP

I love it ... PAIN POINTS ARE SUPPOSED TO BE PAINFUL!  YES!!!

AND ... punishment for not protecting data could be our demise!!!   I love your straight shooting... I had not thought about rewarding people for data protection activities ... a new approach.

I am very frustrated in my current situation where we fail to have governance which ultimately leads to negligence due to ignorance.  I am looking forward to your next post datachick !  Thanks for taking the time to share.

I have a long document running from all the good articles I have read on THWACK! I do appreciate your contribution to my future success!  

MVP
MVP

Nice article datachick

I recommend this article, and support its concepts highly.

Rather than building a fast and insecure solution, then locking it down at the expense of speed (sometimes AFTER the horses were already stolen), I'd much prefer to have every security option implemented  before the produce is made available to users.

Once its solution is secure, only THEN would the apps or database or access be built on top of it.

Then designers' responsibilities are to accommodate the security requirements while simultaneously making the system's speed and accessibility equal to the users' needs--WITHOUT compromising the security.

Next follows continual probing & testing to ensure security's requirements are always met, never compromised for the sake of speed or convenience.  There are many services to do that testing via automation, and I've used Rapid7 and Nessus with satisfaction, along with others.

Continue your best practices for security first.  Ensure they are completed and working properly before accommodating the apps or databases or access, and you'll have built the environment that everyone assumes you'd always built before--something that's secure for them and their data.

Then continue probing, reporting, patching, and updating.

Even though the app or the data or the users' experience is what people see and rate your work on, the unspoken-yet-understood-and-assumed foundation is a secure environment.

Building this any other way won't address the true design problems that cause users to blame security for slowing things down.

Level 12

I’m happy you liked it.  I hope the next posts are helpful as well.

Level 12

The biggest issue for me is that after market security...isn’t that secure.  Or it only protects the data part of the time.

Level 10

Very interesting and makes me wonder if I am doing it right.

Level 12

We should all wonder that, it keeps up on our toes!

Seriously, thought, there isn't as much training out there for data protection at the technical level.  I'm trying to change that.

As we discuss "belling the cat" or lament unsecure implementations, shall we also discuss the root causes?

  • Ignorance.
    • People would (probably) do the job securely if they understood how to do it that way.
    • They'd CERTAINLY do it if there were immediate consequences for NOT creating a secure product and environment.
    • When writers and IT folks find great security to implement, they'll do it, understanding that NOT doing it results in termination
    • People don't know of a way to:
      • First secure the environment and platform
      • Second create an automated security testing and updating solution for the environment and platform
      • Third write the application, or build the database, or service, to perform reliably and quickly enough to satisfy the users
      • Fourth, automatically test the security of the application after it's deployed
  • Budget.
    • If there are ways to address the items above, is there funding to address the ignorance?
    • How will funding be provided to accomplish the security that enables the product to be published or sold or used?
    • Accurate and verifiable figures and statistics that show NOT doing the work securely, NOT designing from the security point of view first, results in lower profits and higher costs, must be found and published.
  • Attitude.
    • If writers or system administrators or Directors or C-Level decision makers don't understand the high costs of preventing or correcting problems, what can be done to educate them?
    • What are you doing to ensure people always choose the secure option before designing a product to be fast?  A product only has to be fast once it's secure.
    • Speedy products, without security coming before the product design, results in someone compromising the product, stealing, or sabotaging the product more quickly and effectively and efficiently.  How are you teaching this attitude to designers and other IT staff, before the product is built and released?
    • If your Marking or P.R. people are assuming your products are built in a secure process that results in the product being reliably secure AND fast, but security is NOT the first ingredient, then they will market and sell based on false information.  And your company will be held liable in multiple ways when its services and products are readily compromised.

Once root concept and idea and tool can overcome all of the above challenges:   TRAINING.

Train people how to design, build, create, deploy, sell, and maintain a product or service securely.  If they don't know HOW to do it securely, they WON'T do it securely.

Train managers and leaders and administrators that they and their staff can't produce or design or release a product or service without the right education.  Train them that budget to teach everyone how to do the job right (with security coming first) MUST be found.  Then deploy that budget to pay for training your people to know how to fill the needs securely.

Train every person to have the understanding of the impact of security training--and also the LACK of security training.

That's simplifies it.  It can all revolve around training; having it, keeping it going, ensuring everyone stays current and up to date on the right procedures, the bad hacks and vulnerabilities, and great ways of avoiding accidentally creating a new product that mistakenly incorporates those vulnerabilities.

MVP
MVP

WOW rschroeder - kudos!!! I did not think that we would get additional stimuli this quickly.  I like your input... you have gone to the golden archive as well!!  Thanks for taking the time.

I am finding sporadic time to spend on THWACK... rschroeder you continue to amaze me by the well thought out and very well organized feedback .. you are one of my heros!!! Keep up the great work!! THANK YOU!!!

MVP
MVP

To reward we must measure. This is true in all aspects work, home, government, etc. There are so many areas that just run on "autopilot" and aren't scrutinized as they should be. We should always have intended destinations in mind with any project, process or plan. Along with the destination there should be checkpoints or "milestones" along the way. With that in mind to reward people for enhanced security we need to know and measure where we are now and where we plan to be in order to know what is appropriate.

This isn't to say that there aren't off the path things that come up and those positive contributions especially need to be rewarded. By rewarding that creativity in thinking we begin to build a culture where people start to think outside the norm and come up with solutions and ideas.

MVP
MVP

I really like how you worded it above .... intended destinations ... do you know how many times we have to run towards a "project" with no final destination .... on a whim ... it wastes valuable time and money!  Rewards these days are far and few between... we need to change this mind set ... we need to stop the ... every man for himself attitude and get back to basics.

Level 12

Looking forward to the rest of this series. We're not implementing any rewards for efforts like this right now, but it'd be interesting to propose it to management. I guess the more creative they are, the better..and we get to secure our data in the process. Win-win

Level 14

Yes, a carrot not a stick approach.  It has been proven many times that incentives work better than punishments.  People will strive towards an incentive but will hope to avoid a punishment.

Level 14

The problem really lays with management.  They want things done now or yesterday and will not allow time for things to be done properly.  Security and testing are usually missed because of this.  There is never time to go back to rectify this.  It would also be more expensive and time consuming to retrospectively do this. 

Level 20

Now with RMF in the DoD space we basically have to document everything... every process and they have to be reviewed and tested annually.

A comprehensive Data Management Strategy is a Must! these days. Big Data is voluminous and can easily spread. Security has to be a priority when controls are put in place. Don't do what we did and try to implement ecurity after the fact. A very steep uphill climb.

Level 16

Thanks for the write up I think people are starting to get it now. A few years ago they would scream and kick all the way when the new compliance and security rules started going in but after all the breaches that have happened they are more open to making it part of

everyone's job and not thinking the 'Security Department' would take care of it. I think it was the IT Auditors that helped a lot in educating people.   

Level 12

I agree.  But I also have some anti-security actions that I believe deserve negative feedback.

About the Author
Data Evangelist Sr. Project Manager and Architect at InfoAdvisors. I'm a consultant, frequent speaker, trainer, blogger. I love all things data. I'm an Microsoft MVP. I work with all kinds of databases in the relational and post-relational world. I'm a NASA 2016 Datanaut! I want you to love your data, too.