Negotiating today's shadow IT labyrinth.

With the proliferation of cloud applications and software-as-a-service (SaaS) overtaking business’ workflows, shadow IT continues to be problematic for IT and security teams. When a department head can purchase a productivity tool using a company credit card, the procurement process is largely abandoned, thus evading any IT oversight that might have been otherwise flagged. Pile atop cloud and SaaS the introduction of internet of things (IoT) devices—anything from smart lightbulbs and thermostats to the new company refrigerator—and you’ve introduced a whole additional layer of network-connected technologies that most likely have not gone through traditional IT procurement review processes—because the procurement of lightbulbs or kitchen gadgets is unlikely to be classified as an IT purchase. While these devices hit the network immediately after implementation, their presence might not be found until many weeks or months later when (if) an asset audit is conducted, a vulnerability assessment or pen test is in the works, or (worst of all), one of these technologies facilitates a breach.

Security teams are on the lookout for these types of issues. Cloud and SaaS have been causing bumps in the secure implementation and management road for many years, and IoT is high on the radar of most security professionals given that the devices, themselves, are being built without much attention to security (despite their internet connectivity). But another area is starting to cause serious headaches for security teams: custom application development.

The evolution of the rogue app developer

Businesses today are application driven. The average company uses hundreds, if not thousands, of applications daily. If your company has a DevOps or a DevSecOps team/process, security is probably aware of the development and deployment of new apps. For a majority of companies, however, relationships between development and IT/security are strained, leading to (among other things) a rise in the “citizen developer ” or “low code revolution.” While Gartner defines a citizen developer as someone sanctioned by the IT department, other sources indicate that citizen developers emerge out of a business need that isn’t being met by the IT or development team.

True enough, according to a survey by Nintex, a workflow automation company, “technology troubleshooting” and “access to tools and documents that enable good job performance” are the most cited broken corporate processes. Ninetex is hardly the first firm to notice that employees are frustrated with IT or security. Security still bears the distinction of “the department of ‘no’” at many organizations, and even when security is called in to collaborate on technology purchases or implementations, it is an inherent part of the job to insert controls and/or conditions that impeded quickness.

Security can't manage what it doesn't know about, yet it's security's responsibility to secure company assets. #InfoSecInsider #infosec Click to Tweet

As such, tech-savvy employees are instigated to create workarounds for broken, slow, or frustrating processes—hence, shadow application development. Much to the chagrin of studied and experienced application developers, emerging companies are developing “low code” platforms that allow people with scant or no coding and development skills to build applications. Largely based on open source code (which may or may not have been thoroughly checked for errors or security weaknesses), platforms like Googler App Maker, Appian, Kintone, OutSystems, and Mendix allow just about anyone to create an app for whatever purpose they desire. And it’s not like business leaders are pushing back on these non-sanctioned apps. According to a survey of 324 citizen developers conducted by Unisphere Research and sponsored by Kintone, organizations’ policies toward non-IT application development are friendly. Only 16% of those surveyed said that non-IT application development is not permitted at the organization, but an equal 16% said they “don’t know” if it’s permitted, meaning that low code development is happening whether IT knows about it or not.

Just like cloud services before it, custom application development feeds into business’ hunger for speed, agility, cost-cutting, and efficiency, and therefore is not a trend that’s likely to disappear anytime soon. From a security point of view, custom app development—or even third-party app development in the cloud, which is accessed by employees through the cloud and never touches the company’s network but yet potentially hosts sensitive company data—presents a shadow tech problem. Security can’t manage what it doesn’t know about, yet it’s security’s responsibility to secure company assets.  

Tackling rogue development head on

What's a security pro to do? Keith Hoodlet, Trust & Security Engineer at Bugcrowd says, "Controlling 'shadow development' and 'shadow infrastructure' (which usually go hand-in-hand, and often resides in the cloud) has become a very real problem in the enterprise today. For better-or-worse, accessibility to training and materials for learning how to code is ubiquitous—and this information rarely contains lessons on good security hygiene." 

Hoodlet says that while some shadow development is inevitable, it doesn't have to be a free-for-all. "First and foremost," he advocates, "identifying the organization's critical assets is key. Technical controls—such as locking down (and logging developer access to) administrative or internal API's—allows security teams to quickly identify and remediate threats that could lead to catastrophic outcomes later. Likewise, restricting (and monitoring) access to production databases will help prevent the kind of outcomes where a so-called 'citizen developer' leaves a copy of the production database open to the internet on an un-authenticated Amazon S3 bucket. These kinds of technical controls—by way of identifying and locking down critical assets that development teams interface with—allows for security professionals to maintain some semblance of sanity as it relates to rogue development."

To remedy the problem, Hoodlet provides this advice to security teams:

  1. Work closely with your organization's technical program managers (if you have them). Doing so will ensure that good security hygiene is encouraged and rewarded and may help drive a more security-conscious culture.

  2. Build inroads and relationships with development teams, if they exist at your organization. These are the people often leveraged as resources by citizen developer colleagues and can help identify rogue or risky development. They key to success is becoming embedded in the development process. If possible, hire an application security engineer to act as an ambassador between development and security teams. This person can help identify (and to some extent, prevent) when "citizen development" turns into "exploitable development."

  3. Look into—and make use of—the OWASP Application Security Verification Standard (OWASP ASVS). After all, Hoodlet reminds, us, "an ounce of prevention is worth a pound of cure."

Want to learn more about becoming a security-conscious developer? Keith will present "Attack Driven Development" at InfoSec World 2018, on March 20th at 4:00 PM ET.