eBOOK

10 Ways We Can Steal

Your Data
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

Table of Contents
1 INTRODUCTION 3

2 THE PEOPLE PROBLEM 4

I just need to get this fixed 4

I need a solution now 5

We need you to work 24/7, and then some 6

We need test data, and we need it now 7

We ask for it 8

You just give information without us even asking for it 8

3 THE PHYSICAL SECURITY PROBLEM 10

The paperless office myth 10

End-to-end testing 10

Backup media 11

Who goes there? 11

4 HOW TO KEEP US FROM STEALING YOUR DATA 13

5 CONCLUSION AND CONSIDERATIONS 15

Data Governance 15

Threat detection 16

Unusual loads 16

Data access 16

Unexpected performance issues 16

Alerting 17

6 ABOUT THE AUTHOR 17

page 2
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

Introduction
In 2016, there were billions of records exposed in data breaches1. Today, reports of data breaches
are growing at a rate of 40% each year2. As the number of breaches increases, so do the number
of books and articles written about ways to secure data from hackers and theft.

This book is going to take a different approach than most data security books. In this eBook,
we are not going to cover the basics. Instead, we’ll focus on outlier, or less obvious situations
that IT professionals don’t usually consider when they think their organization is leaking data.

We have placed these outliers into two groups: the People Problem and Physical Security. Under
those headings, we list 10 ways that your data could be vulnerable to theft or loss. We then offer
practical tips on how to prevent your data from being lost or stolen. These are tips you can start
using today to minimize your risk.

Lastly, we will finish with some additional techniques you can use to help prevent data theft.

page 3
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

The People Problem

In Secrets of Consulting, Jerry Weinberg writes, “No matter how it looks at first, it’s always a
people problem.” Certainly, many data breaches happen for what appear to exclusively be
technical reasons, but eventually, we follow the causes to a person. The people may or may not
be to blame, but they certainly are related to the cause.

People can steal your data by taking advantage of human factors. Besides the frequently cited
cases of social engineering, these human factors are the ones that we see each day in corporate
enterprise shops around the world.

I JUST NEED TO GET THIS FIXED!

Picture a quality assurance tester who wants to get help from the development team in another
city. The team, working for an outside contractor, cannot reproduce the bug she has logged. They
have asked for a backup of her test database to help track it down. She can’t make a backup,
but she can export some of the data to share with the other team.

They do not have access to her machine, nor a secured, shared resource or drive. She zips up
her sample data file and emails it to them so that they can just get this complicated bug fixed.
The team on the other side places the file on their shared drive accessible to all staff at their
company. They then restore the file to a developer’s laptop, import the data, and get to work
trying to figure out why the bug was happening. They look at the data, they run the app, and
they ask others about the problem. They even include some sample XML to get others to help
them diagnose the issue.

page 4
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

We now have several unencrypted and unsecured copies of the data:

»» 1. The QA machine still has the file, one that no DBA or security analyst knows about

»» 2. The tester copied that file to her own laptop for emailing

»» 3. The tester has a copy of the backup in her mail, as does every server that was involved in
sending that email

»» 4. The recipients of the file on the developer team has a copy

»» 5. The shared server has a copy

»» 6. The developer has a copy

»» 7. The data is now imported to a development DB that may or may not be secured

That data might as well be pegged to a grocery store bulletin board by now. Sure, some of this
data may have been shared over secure connections. Maybe it was encrypted. Maybe no one
copied it to a thumb drive or put it on a public share to work with it elsewhere.

But then again, maybe they did.

There are at least seven places we could go look to steal this data. Some of them are easier to
find than others, but none of them take much effort to access. Some places just need to have
a script run against a group of IP addresses or services to find the data.

A team member under pressure to solve a problem made a poor decision because there was no
standardized way to share sensitive data with other team members.

1. You don’t provide reliable and secure ways to share access to sensitive data.

I NEED A SOLUTION NOW!

The development team is having problems getting a connection to work for Database A from
Application One. They’ve read the vendor documents. They’ve tried solutions mentioned on a
few blogs. They are under pressure and they need to make this one weird connection work. Now
they are going to try to get help from a forum or a mailing list.

They post their question, along with their connection strings that aren’t working, plus the
configuration file for their web server.

page 5
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

And now the entire internet knows the server names, IP addresses, database credentials,
encryption keys, and web host information for production systems. The internet never forgets,
either. Forum managers work to help posters understand that these files tend to hold sensitive
data that can be used not just to help solve a problem, but also to give anyone reading the post
access to those systems. Even if the developer is working in a development environment, he
may have exposed enough information to help people like us get access to resources we should
not have access to.

As another example, a DBA may be having issues trying to tune a query or to solve a resource
contention issue. So, she exports a query plan that has real parameters embedded or exports
XML from her monitoring tools to get others to help her diagnose those issues. Maybe she
uploads it to a website that helps her understand the query plan better. Either way, she may be
posting real data or infrastructure resources that may entice people like us to go poking around
to see what we can find. Or maybe she isn’t in charge of the web host configuration file, but
when asked for it, she finds and provides it.

An IT professional under pressure to solve a production problem loses sight of or doesn’t know
that the metadata and configuration data she is sharing has information that should have
been removed.

2. In your rush to find a solution, you don’t collaborate across teams when outsiders are
involved in troubleshooting.

WE NEED YOU TO WORK 24/7, AND THEN SOME

These days, most IT professionals work from laptops and tablets. Sometimes they bring their
own equipment to use as their work machines. This means we can all carry our work with us
everywhere we go.

We should work to ensure that our personal work devices are as secure as an enterprise-
issued machine. These steps may feel like obstacles, but they are necessary. When working
with a local copy of a development database, developer laptops should be configured with data
protection applications such as anti-virus, anti-malware, encryption and regular patching. Our
own machines should also be monitored for this level of compliance.

Applying current patches was an important mitigation for avoiding ransomware in attacks that
encrypted data via malware. But there was no reason why that attack had to stop at encryption.
Once this malware had infected a drive, it could have copied data just as easily.

Even if the laptops are used only for remote access to production environments, laptop access
should be secured by enterprise-class applications and processes.

page 6
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

Network connections should never be set to auto connect, which causes their Wi-Fi card to
broadcast their work Wi-Fi connections to the world every place they go. We might set up a
spoof Wi-Fi with the same name in their local coffee shop, giving us access to their unsecured
connection. There are numerous ways we can steal your data via unsecured developer machines.

3. You don’t require secure connections and configurations for all devices that connect to
organizational resources.

WE NEED TEST DATA, AND WE NEED IT NOW

We know what you’re thinking. Test data doesn’t matter because the teams are not using
production data for development and testing, right? No, because the test data is a backup of
production data. Maybe they deleted some of the rows to make the test database smaller. Maybe
they tried to obfuscate some of the data. Certainly, they didn’t export unencrypted data because
that makes development, debugging, and testing applications easier.

The development team wanted to use test data that they created, but they underestimated how
long it would take to make up all the possible complexities of the real world. So, they just decided
to use production data. Because it’s fast. And it’s there. And it’s easy. And they are allowed to,
for some reason. Or management assumes that’s the only way to test an application.

Often development and test environments are not as locked down and monitored as production
environments. This is partially due to other teams not knowing that production data is being
used in these environments, but it can be due to development teams not understanding that
their systems are just as much as a target as production ones.

Often, we hear how IT professionals are using production data to do daily development and
testing. In fact, they do this so often they have customer details memorized. They know who
shops where, what credit cards they use, and what they buy. Where they bank. Where they
live. The effect of using production data in dev/test is that privacy is at a greater risk because
developers and testers are working with the same production data every day for years. It’s
scary how these customers, sometimes even your neighbors, become the lorem ipsum of an
organization without ever knowing their data is being used like that.

If the teams were using true test data, a breach would be mostly harmless. But we know that
teams do use production data, which just magnifies the risk of our stealing your data.

4. You use production data for development and test data.

page 7
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

WE ASK FOR IT
Try this out: Start a conversation with a group of IT professionals about passwords and IT
standards for passwords. Soon you will find people discussing their password invention
strategies and often they will start telling you the types or the actual passwords they use for
their own logins. Or they will tell you the exact algorithm they use. For example, “My sports
team plus the first three letters of the domain plus a number.” If you ask about the funny group
accounts they use, they will tell you the funny names they make up for them. Then the funny
passwords. You’d think that IT professionals would know better, but we don’t.

The same trick also works for talking to people about how they name servers, databases,
and tables.

Another trick is to get IT professionals to discuss their approaches to security configuration,

especially if there are contentious issues about a practice. Go to social media and ask if IT
professionals think it’s important to change a database’s default port. No matter what they say,
respond by telling them they are wrong. Many will likely respond with their shop standards and
why your position is wrong. Maybe they don’t use 1433, but use the first prime number after
that. Perhaps they shouldn’t be making their database accessible to the internet, but if they do,
we can ask them how they do it.

Maybe everyone in IT is given admin access to development and test environments to make
their jobs easier. But remember how you said you need to use production data in dev/test? You
just gave many people access to production data without giving them access to production.
Perhaps you require IT professionals to put in a request for access to these resources. Has
anyone ever been turned down for access to development and test environments after they tell
you they can develop and test faster? We don’t think so.

Even if you try to configure development environments with security features similar to production,
if you grant elevated permissions to almost everyone, that security won’t be strong enough.

5. You tell us how to take your data.

YOU JUST GIVE INFORMATION WITHOUT US EVEN ASKING FOR IT

Troy Hunt of haveibeenpwnd.com publishes a list of passwords from most major breaches,
covering millions of passwords. He even suggests checking user passwords against these lists
to help ensure that credential stuffing—using the same credentials in more than one place—is
mitigated. We may be able to guess passwords faster than trying all possible combinations by
using leaked credentials for an IT professional’s email address from one service on another
service. We won’t even have to do a phishing or spearfishing exercise.

page 8
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

The advent of affordable, easy-to-procure cloud services has made it easy for IT professionals
to host shareable data in the cloud. Way too easy, in fact. A sizable number of data breaches
have occurred because someone posted data or a data backup to one of these open sharing
services with no security.

Another example of giving us data is when applications and services are installed with default
credentials. The most notable example is Internet of Things (IoT) devices. But even some
database management systems and applications can be installed without providing a new
password at installation. All we need is a good scanning utility and maybe a list of default
administrator logins and passwords.

In these cases, we don’t have to bother you at all to steal your data; you left it there for us to find.

6. You let us find and take your data.

Now that we’ve covered the “people problem” scenarios, let’s shift our focus to the physical
security problem.

page 9
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

The Physical Security Problem

We’re all familiar with the password-taped-to-the-monitor issue with physical security. Sure, it
still happens, but there are other versions of the same kind of oversharing that happens with
IT professionals.

THE PAPERLESS OFFICE MYTH

Does your organization apply the same level of security to paper printouts that they do to online
files? Does your security auditing process look for sensitive data in trash and recycle containers
where papers should have been placed in shredding collectors?

What happens to paper applications that customers fill out in retail locations? At one membership
retailer, we found binders of applications being used to prop open outside doors during hot
weather. Hundreds of applications were being stored in those binders out on the sidewalk, just
waiting for someone to walk away with them.

IT professionals like to think they have a good handle on security, including encryption, strong
access policies, and monitoring. But we rarely think about paper artifacts and how they should
be secured.

7. You don’t know or don’t care how paper artifacts are managed or secured.

END-TO-END TESTING
Recently, there was a news report about how sensitive medical data was exposed 3 because
letters sent to patients were contained in envelopes with larger-than-expected windows. A
sizable portion of the contents were viewable, which allowed anyone looking at the envelope to
see the patient’s health information. This data breach would have been caught if data lifecycle
testing was done completely end-to-end, from input processing to mailing.

page 10
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

Another mailing data leak happened when developers used a rarely populated field to store
sensitive data rather than opening a change request to create a properly secured column in the
database. Report designers for a new system, not knowing that this column was living a double
life, displayed that data on an output that exposed the sensitive data to the world.

This would have been found if data profiling of the legacy data had been completed as part of
end-to-end testing.

8. You don’t test your systems from end to end.

BACKUP MEDIA
You know to schedule backups. You know to automate restore testing. (You do automatically
test your restores, right?) Do you know how backup media is managed from your data center
to off-site locations? Is it picked up by a courier, or perhaps the off-site backup vendor? Does
someone have to walk it over to the local shipping service? Is it placed on a cart in the lobby
waiting to be picked up? Is it encrypted? Or is it waiting for us to drop by and see what we can
take just by visiting your shipping area?

Is someone backing up your databases to a cloud service/storage bucket that isn’t secure? Or
worse, completely open and public? How do you know for sure?

Do you think this is all someone else’s responsibility to know these answers? If so, you might
just have left us several ways to steal your data. Plus, you might not find out about it until you
read it in the news.

9. You don’t know or don’t care how backup media is managed and secured.

WHO GOES THERE?

With distributed teams, office hoteling, and shifting work hours, we don’t often recognize all the
people we work with in our physical environment. We don’t always know who is supposed to be
in the office or data center at any specific time.

Imagine a network administrator who has been let go late on Friday showing up to work on
Saturday, saying he forgot his badge and entry card. Because he was told to go home on Friday
and the job to remove his access wasn’t completed before the weekend, his access has not
been removed. The security guard recognizes him and gives him a forgotten badge pass and
a key card with his usual accesses. He’s now wandering around the floor and the data center,
looking for valuable data.

And these days, he might not even have to show up at the office. He might be sitting at home,
accessing all the resources using the group login for his department because no one thought
to cycle the passwords for all those accounts before the weekend.

page 11
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

What if he decides to pick up all the backup media waiting for pickup on that cart in the hallway?

This is why even well-respected, trusted staff should be properly processed out of an
organization. This is why you shouldn’t use shared accounts, but role-based permissions. This
is why physical security is just as important as remote security, and vice versa.

We can steal your data that way just by focusing on former employees, who sometimes look
for independent income between jobs.

10. You think your job is only about online security.

Now that we’ve shown you 10 ways we can steal your data, let’s talk about ways you can avoid
each of the scenarios above.

page 12
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

How to Keep Us From Stealing

Your Data
1. You don’t provide any reliable and secure ways to share access to sensitive data.

Start providing ways for business users and IT professionals to approve the sharing of sensitive
data. Train them on how to use the approval process system, what the approval process is, then
monitor for usages of data sharing through other means. This fix also requires that employees
understand the importance of data security, and know that there will be repercussions if security
process requirements aren’t followed, even if they are under pressure to fix a bug or get a code
to work.

2. You don’t collaborate across teams when outsiders are involved in troubleshooting.

Ensure that team members know that providing a file or other resource may include security
information that should never be shared. Encourage team members to use better security
credential management and best practices for protecting configuration data. Encourage team
members to collaborate when getting third-party support, even from regular and trusted resources.

3. You don’t require secure connections and configurations for all devices that connect to
organizational resources.

Ideally, devices that access sensitive data would be managed and controlled by enterprise
processes. That means encrypted storage, managed group policies, secured logins, and
secured configurations. Required access to data should be provided only via VPN or other
secure mechanisms.

4. You use production data for development and test data.

Stop.

Just don’t.

If you insist on doing this, you may want to check to see if this use of data complies with security
and privacy regulations that apply to this data and your organization. If it does (and we doubt
it), secure the development and test environments the same way you would production data.
That should include restrictions on accessing private or sensitive data. It should also include
monitoring for data snooping of celebrity or protected accounts.

But, really. Just start developing your own enterprise test data that tests all your test cases (it’s
common for current production data to not do so). Then use it.

page 13
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

5. You tell us how to take your data.

Stop talking casually about your personal and professional security approaches. Sure, you can
talk about general security policies and issues, their trade-offs, and how one might choose the
best approach in general. Once you start bragging about specifics, you’ve probably crossed the
line to oversharing.

Be extremely cautious about posting files, resources, questions, and sample code to forums and
distribution lists. When seeking support, be cognizant of what you are sharing and what your
organization’s policy is on sharing data or code with third parties. Don’t do it alone. Ask team
members for help if you are asked to provide content you don’t understand. Don’t run scripts
sent from people trying to help. Don’t run scripts without testing them. Don’t upload files to
third-party sites unless you are certain the files do not contain any real data.

6. You let us find and take your data.

This is a tough one. Breaches like these are common because they are hard to detect and
often done by staff members who have no idea that they’ve used an unsecured resource to
host or share data. They don’t know that the resource they are using was installed with default
configurations and credentials. Or they knew and forgot.

The best mitigation against this is having a good governance process for deploying new services
and applications, plus education and awareness.

7. You don’t know or don’t care how paper artifacts are managed or secured.

First, start caring. Find out how paper artifacts are created, managed, stored, and disposed of. If
you think it’s not your job, then find out whose job it is and talk about how this data is protected
before it is entered into applications and how it’s protected as outputs. Make sure there are
user stories (requirements) and test cases for these items. If you can’t find the person whose
job it is to protect this data, raise this as an issue to management. At some point, someone is
going to blame an IT professional for not protecting the data. Position yourself so that it’s not
you who said, “That’s not my job.”

8. You don’t test your systems from end to end.

Start testing your systems end to end. Make sure there’s a test plan for doing so, even if you
aren’t the person to run and report on that test. If you think it isn’t your job, find out whose job it
is. The same as above: if you can’t find out who, report this as an issue to management.

9. You don’t know or don’t care how backup media is managed and secured.

Find out how backup media is secured, managed, and transported. Find out how it is re-used or
disposed of. There are a few resources to help manage an entire backup and recovery strategy,
but first you need to know the current status.

page 14
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

10. You think your job is only about online security.

One way to mitigate your risk of lost or stolen data is to limit physical access to the data itself.
This means limiting the number of people who have access to the data center, as well as logging
the entry and exit of employees inside your data center. It means having security processes that
reach even to the door and badge security department.

But the data center isn’t the only place where data can be stolen. You should also limit the ability
for anyone to walk through your office without being identified. That’s how laptops get stolen,
or server tape drives fall off a cart on their way to remote storage.

Physical security includes badging and keys. Remote access sits in the grey area between
physical security and online security, especially in organizations where virtual desktops are the
medium through which everyone accesses company resources.

Conclusion and Considerations

We’ve discussed 10 ways we can steal your data, most without having to resort to highly
technical hacking techniques. People will continue to be the weakest link in data protection.
Physical security and protection of physical documents should be included in data protection
strategies and processes. Because IT professionals are expected to do more with less, we may
be missing these important vulnerabilities in our day-to-day responsibilities.

Data security and privacy are areas of growing concern to many corporations and consumers.
Data is the most critical asset your company owns, and it’s about time we started treating it as
such. When it comes to protecting your data from theft, you have six major focus areas to help
mitigate your risk. They are data governance, threat detection, unusual workloads, data access,
unexpected performance issues, and alerting.

DATA GOVERNANCE
You need to understand how and what data needs to be encrypted. To do this, you’ll need to
understand the nature of data and how you are required, through legislation or organizational
policy, for encryption. Most organizations are required to encrypt personally identifiable data
and sensitive data like payment types, health, and financial information.

You can use software such as Bitlocker to encrypt devices. And you can use database encryption
®

methods to further secure the data. All traffic in and out of your company should be done using
SSL to avoid man-in-the-middle attacks.

page 15
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

THREAT DETECTION
Encryption and physical security are good, but not enough to protect your data. Threats exist
from within your company as well as from outside. Users with appropriate access can run
queries against more data than necessary. SQL injection attacks are another area of concern.
It is difficult to protect your data and allow for appropriate usage by authorized personal.

Vendors now offer threat detection as a service, such as Microsoft SQL Threat Detection
®

services in Azure . You can be alerted to possible SQL injection attacks, suspicious database
®

activity, and even anomalous data access patterns. Threat detection makes it easy to respond
to issues without needing to be an expert in security or manage complex security systems.

UNUSUAL LOADS
One aspect of SQL Injection attacks is that they tend to do a lot of work, such as reading (or
deleting) from entire tables. Therefore, you should be monitoring for this type of activity. One
way to do this is to gather performance metrics to look at trends over time versus a single
point. This way, if an attacker tries to access 20 years’ worth of customer sales data, you will
recognize this as an anomaly. Another way is to look at query syntax and flag queries that use
SELECT ‘ syntax for further review.

DATA ACCESS
By collecting query and performance data over time, we can also determine which tables are
being accessed most frequently. That way, if we suddenly see that some tables are being
accessed that haven’t been touched, we can ask questions. Another item could be backups.
We can track to see if backups were done to a network share or URL we haven’t seen before.

UNEXPECTED PERFORMANCE ISSUES

With baseline performance data in place, sudden performance issues could shed light on
unusual activity. An attacker may be hitting a frequently used table, and they may not be trying
to get all the data, but their presence could be causing performance issues for someone else.
For example, an attacker may have access to a reporting system that would reveal customer
information. The report isn’t anything unusual; it’s run all the time. But the attacker runs it at
midnight, causing locking and blocking issues for the accounting team.

page 16
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

ALERTING
You should configure alerts to notify you that action is needed. If there is no action to be taken,
then don’t send an alert. Log the details of the incident for later review. If you send too many
alerts, you won’t know which ones are important.

Remember that loving your data includes protecting it throughout its lifecycle, in all its formats.

SOLARWINDS SOLUTIONS
Database Performance Analyzer (DPA)

Encrypting your database data at rest can cause performance overhead. You better have a tool
to show how much of a hit encrypting data at rest causes for production. Start your free 14-day
trial of DPA today.

SIEM: Log & Event Manager (LEM)

A SIEM that makes it easy to use logs for security, compliance, and troubleshooting. Start your
free 14-day trial of LEM today.

1. https://haveibeenpwned.com/
2. http://www.idtheftcenter.org/Press-Releases/2016databreachespressrelease
3. http://www.npr.org/sections/thetwo-way/2017/08/25/546048615/aetna-mailer-accidentally-reveals-hiv-status-of-up-to-12-000-patients

page 17
eBOOK: 10 WAYS WE CAN STEAL YOUR DATA

About the Author

Sr. Project Manager, InfoAdvisors

Karen Lopez is Sr. Project Manager and Architect at InfoAdvisors. She has 20+ years of
experience in project and data management on large, multi-project programs. Karen specializes
in the practical application of data management principles. She is a frequent speaker, blogger
and panelist on data quality, data governance, logical and physical modeling, data compliance,
development methodologies and social issues in computing. Karen is an active user on social
media and has been named one of the top 3 technology influencers by IBM Canada and one of
the top 17 women in information management by Information Management Magazine. She is a
Microsoft SQL Server MVP, specializing in data modeling and database design. She’s an advisor
to the DAMA, International Board and a member of the Advisory Board of Zachman, International.

© 2017 SolarWinds Worldwide, LLC. All rights reserved.

The SolarWinds, SolarWinds & Design, Orion, and THWACK trademarks are the exclusive property of SolarWinds Worldwide, LLC
or its affiliates, are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other
countries. All other SolarWinds trademarks, service marks, and logos may be common law marks or are registered or pending
registration. All other trademarks mentioned herein are used for identification purposes only and are trademarks of (and may
be registered trademarks) of their respective companies.

page 18