Do you ever wish security would stop blocking the tools you need to do your job? Surprise: your security team wants the same.

There you are, just trying to get your work done, when…

• You need an AI to translate documentation, but all the AI services are blocked by a security web monitoring tool.
• You finish coding and QA for a new software version just under the wire, but the release is late because security has not reviewed the open source software and libraries included.
• Your new database works perfectly in dev/test, but it does not work in production because of a port configuration, and you do not have permissions. Changes to production permissions all require security approval

Here Comes… Shadow IT

Shadow IT is a spy-movie name for a phenomenon that is either a frustrating necessity or a game of whack-a-mole, depending on your responsibilities.

If you’re an engineer creating the next best product, shadow IT is a necessity.

Company-supplied information technology does not change fast enough to keep up with the market, let alone allow you to innovate. Despite that, your security team will come down hard on anyone who tries to go outside the allowed vendors and products. Data storage has to be squared away in encrypted, protected spaces, and you have to jump like a show pony to get access. And you have no flexibility in the tools you’re allowed to use, even if you could produce faster and better with other options.

So you stop playing by the rules, and you find tools and tech that work.

That is, until someone protests the cloud hosting bill, finds the wifi access point, or notices the unofficial software repository. Security takes away your tools or cuts off access. And then you are upset, your team feels attacked, and security is up in arms.

If you are on a security team, shadow IT is a game of whack-a-mole. Company-supplied information technology changes without review. You know they’re trying to enable innovation, but they’re negating all the IT compliance certifications that allow you to sell your services and products. You have to investigate, prove, and argue about policies and regulations just to stop people from storing client secrets in their personal cloud storage.

Whether you are a new hire in the Security Operations Center or the unlucky CISO who reports to the CTO, this is a familiar refrain.

Yet no one wants this. Not you, not your boss, and not security.

If It Cannot Be Fixed, Break It

It’s time we change the ground rules of security to focus on compromise rather than stringency.

Most security teams *want* to change their operations to concentrate on the capabilities they are trained for: threat intelligence, risk management, forensic analysis, and security engineering. I have never met a security professional who wants to spend their time arguing over a port configuration. It’s tiresome, and that friction inspires lasting antagonism on both sides.

Imagine working in a place where you can use innovative new tools, release products without a security delay, and change configurations so that your deployment works smoothly.

We can have this.

But there is a subtle change that must happen to enable this security-IT paradise: non-security teams would have to understand and implement all the requirements security departments would check. And everyone who is part of the change would need to understand the implications of their actions and take sole responsibility for the security outcomes.

Let Security Let Go

My non-IT colleagues are shocked when I explain the scope of work for a security department in preparation for any release or product launch:

• Weaknesses and exploits for custom and third-party code
• Scope and adequacy of vendor security
• Data encryption, transmission, and storage, especially across borders
• Compliance with regulation and data protection laws

In many industries, we legally cannot remove security practices from IT processes. But we can change who takes responsibility for which parts of the work

Security requirements are not a secret. A developer with integrated code scanners can avoid OWASP Top 10 flaws and vulnerable libraries and remove hard-coded accounts. Infrastructure admins with access to network security tools can run tidy networks, servers, and containers with precise configurations.

The result? The security team can let go of their rigid deployment rules.

If developers use code security tools and incorporate good practices, security team approval should take hours rather than days or weeks. Security can also approve the standard container configuration rather than each separate container in an architecture. They can define the requirements, offer you tools to review your work, and help you integrate good practices into your workflow.

“Trust but verify” would become a daily pattern instead of lip service to good interdepartmental relationships. Security will continue to monitor the environment and the application after release. They will keep an eye on vendor assertions and audits, watching threat intelligence streams for notifications that demonstrate risk. Security teams will have time to do the job they signed up for, which is much more interesting than policing other departments.

This change would also require that the security team be *allowed* to let go. When trust is broken—if vendors are not properly assessed, or software is introduced but not reported—the fault should not lie with the security team. If insecure coding causes a compromise, the development team must be accountable, and if an inadequately configured network causes a data leak, the network and hosting team must be called on the carpet. If the requirements are in place but not met, the responsible parties must be those that agreed to them but neglected to enact them.

Freedom to Choose Comes with a Catch

This new freedom makes shadow IT unnecessary. Teams do not need to hide the choices they make. However, the freedom to choose comes with a catch: full responsibility for your choices.

Consider the company charge card: Finance teams create the policy for how to use company charge cards and provide the tools for reimbursement. They do not scrutinize every charge in real time, but they review usage and payments.

If the tool is abused and the agreed-upon care is ignored, the card user is held responsible. Any lack of knowledge does not exempt you from the consequences. For minor infractions, you may get a written notice. For severe infractions, you can expect to be terminated for cause.

The finance requirements, your agreement, regular review, and enacted consequences minimize fraud internally. More importantly, though, this combination protects the company against accusations of negligence.

Security responsibility could work the same. Security teams can set requirements that IT workers agree to individually. IT teams are then free to deploy and make changes as appropriate for their work. IT secures assets before they are put into production, and security continues with the best practice of reviewing assets continuously after the fact. Delays in getting the tools you need are reduced, and you control the deployment of your work with much more assurance. The incentive for shadow IT is much lower, and the personal risk of choosing it is higher.

That last bit is the catch, though—when you take control, you take responsibility for the result. Instead of committing to a patch, you back out insecure code and redeploy when it is corrected. When your department contracts with a squirrelly vendor, your manager’s budget takes the hit for breaking the contract. When the network is compromised, the CIO, not the CISO, gets fired.

Right now, the security team carries this responsibility and shoulders these risks. But the result is an enterprise held hostage by risk aversion, with no understanding or control over the outcomes.

So far, I’ve mostly addressed IT, but I also want to bring this argument back home: Security professionals, let’s stop taking control of everyone else’s work. When we make hard requirements that do not meet tech realities, our IT teams get better at hiding their tracks. You will make more progress if you invest in mutual success and reward people who step up to exceed your expectations.

When Security and IT Make Peace, Shadow IT Becomes Unnecessary

I once worked with a development team that wanted to store proprietary code in a hosted code repository. The repository was great for their needs: versioning automation, fine-grained access management, easy branching, access from anywhere, and centralized storage. Instead of waiting six months for the new vendor security investigation process, the developer team gathered the vendor’s audit certificates, data handling guarantees, and standard contract language about security and data mining. The devs proactively researched the third-party security scanning policies and asked for their incident response and notification policies.

Our security team would have struggled to locate this repository if the developers had simply chosen to use it. Instead, they circumvented our process in the best way—by providing every necessary answer to our security questions.

The reward was an instant yes from me, the security leader, without having to wait for my overworked team to schedule yet another vendor review.

My reward? No shadow IT plus a very happy IT team.

Security should go beyond allowing compromises like this: we should seek them out. Convince the CISO to work toward giving your IT teams both control and responsibility, find a compromise with the teams that will take security seriously—and save your energy for wrangling teams that don’t.

For admins and developers: Provide the ISO audit documents for that vendor you want to use. Be the first dev team to learn the org’s code scanning tool. Read the latest risk assessments from your cloud environment and don’t repeat vulnerable configurations. These small changes make your work faster, simpler, and less expensive than finding your own solutions.