Carol discusses the dangers of allowing IT projects outside of the IT team and the problems doing so can present to your organization.

I've heard them called by several terms—"rogue IT", "super users," and most commonly, "shadow IT"—but essentially it's those users who perform duties that would normally be done by traditional IT staff…but these workers don't work for IT. Often, these workers have a background in IT, having moved from a position in IT to a position on the business side of the organization. They think that since they know how to perform these tasks (writing queries, replicating databases, developing complex spreadsheets, etc.), they might as well do the work. No harm, right?

Another way this type of IT work gets done by business workers is when IT is overworked and their requests can't be fulfilled in the timeframe required by the business. Again, if the IT staff can't do it and someone else can, then it's actually helping IT, right? Finally, some people in business are so clueless to the need to involve IT that when they have a need they go and solve it themselves. None of these scenarios purposefully sets out to harm the business. In fact, the intent is to move the business along. But these activities can pose significant risk to the organization. Let's look at how.

Copies of Existing Databases

Shadow IT often implements alternative databases of existing business data—either in part or in whole. This can happen when the business doesn't have a formal data warehouse, or the warehouse doesn't have the data they require, or the data warehouse team isn't immediately available to update the warehouse with the required data, or IT isn't available to write new queries. This practice can cause many problems, including:

• Alternative databases are usually not secured as stringently as the original database. Therefore, confidential data may not be protected at all or may be available to users without a business need.

• Rogue databases may put the organization out of compliance with laws and regulations such as the Payment Card Industry's Data Security Standard (PCI DSS), EU Data Protection Directives, and HIPAA, to name a few. In addition, loss of data via these databases may cause an organization to have to report lost or stolen data per various state or country breach notification laws.

• Because this is "raw" data, any business logic that was in place when the data was accessed via the original data application interfaces is gone and the data is available to anyone with access to this alternate database. This may expose this data to business users who would not normally have access to the data. For example, if sales data is available only to users in a particular region via the sales application but the data for all sales has been copied to a database on a Windows server available to all users, sales personnel will be able to see sales information for all regions, not just their own.

• Business decisions may be made on different versions of the data. Because there are multiple copies of the database, someone may be viewing a report pulled from the original system (e.g., an IBM i) and another may be viewing a report generated from the Windows Server copy. What if someone accidentally (or purposefully) modified the Windows copy without anyone noticing? What happens when someone notices that there are two sets of data being used for analysis? How long will it take to determine which set is correct?

Data of Record

When the shadow IT project is not based off of existing data but rather is a new project, the rogue database is the database of record. In other words, this is the original and perhaps only database in which this data resides. As such, this database should comply with all of the organization's data requirements (which it would if IT were involved) but often doesn't. For example:

• Is the rogue database backed up? If it's backed up, where is the media stored?

• Has the database been added to the organization's disaster recovery plan?

• Does the database comply with the organization's data retention policies (both for retaining as well as deleting obsolete data)?

• Is the data secured according to the organization's data security policies, including encryption requirements? Is the data secured so that it can't be modified except by approved users? In other words, can you rely on the integrity of this data? As a business woman, the thought of making business decisions based on inaccurate data sends shivers down my spine.

Technology Integration

Or I should say lack of technology integration? I've seen cases where IT is bypassed and then eventually asked to support the rogue IT solution that was implemented by the business. The problem was that the solution that was chosen was done without regard to the technology already in place or the scalability of the solution or whether it could "talk to" other applications already implemented. New equipment had to be purchased even though solutions existed on the technology that was already in place. Integration couldn't occur or was going to be extremely expensive to implement because of the lack of integration. Finally, administrators had to learn new skills because of the new technology. In the end, this rogue IT solution actually cost the organization significantly more than if the business had waited a couple of months for the IT staff to have time to be part of the requirements discussions and solution implementation.

Summary

I realize that I probably haven't told you anything new. In fact, you could probably list issues that shadow IT causes that I've forgotten. What I hope this article does is to give you an outsider's view of the situation that may help persuade your management to not allow rogue IT to occur. If that doesn't work, I recommend that you start keeping a record of all of the issues that shadow IT causes—and not just the things that cause you pain in your behind. Keep track of the issues along with the cost and ramifications to the overall organization. If you simply list the issues, management will just write you off as a complainer. However, if you keep the list and show how the business would have been better off if the project was done through and with the support of IT, you have a much better chance of being heard.

Or you could just print out this article and put it on management's desk.

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale

Also Read

Authentication and Authorization: Why? Part 3: A Word About Privileged Account Management

Authentication and Authorization: Why? Part 2: Query-Response Language & Policies

Authentication and Authorization: Why? Part 1: Access