How to Keep Your Apps Secure After Moving to SaaS From On-Prem

The world of how work gets done has changed dramatically, moving at a faster pace with a far greater emphasis on collaboration for improving productivity. Today, virtually all software has a cloud component. This can be as simple as the application or operating system’s update mechanism, or it can be that on-premises software has been replaced by full-blown Software as a Service (SaaS) products. Recognized for offering many advantages, cloud-integrated solutions are rapidly growing in popularity. However in order to make the most out of their use, careful planning is the key to safely unlocking their capabilities.

There are very real concerns associated with the use of cloud-integrated software. Information stored in our computers is often among the most valuable assets an organization has. As a result, the digital solutions an organization selects are a careful balance between price, functionality, and the risk that an organization’s digital assets might be exposed to competitors, or made vulnerable to malicious compromise.

Customer lists and histories offer established organizations a competitive edge, while trade secrets and critical business processes can be found detailed in files as mundane as PowerPoint presentations. An organization’s source code can be a goldmine of critical information.

The value of source code means that the idea of cloud-integrating any part of the development process is a common source of anxiety. It also makes for a great example use case to discuss the real world implications of cloud integration of sensitive workloads.

Common Concerns

Application development is no longer a niche area of work reserved for companies that make their business solely from writing programs. Despite the number of software vendors in the world, there is still a regular need for custom software. Organizations of all sizes develop applications to deliver solutions to end customers, whether they be for internal or external use. Also common is the development of custom middleware to glue together multiple different digital solutions with the goal of increasing automation.

These custom applications are the digital implementations of the very trade secrets that provide an organization an advantage over its competitors. Business processes, testing automation, logistics integration, recipes, and more can all be mined from an organization’s source code.

Vulnerabilities in custom-built applications come from one of two primary sources: bugs in the code written by the application’s developers, and bugs in the third-party libraries, frameworks, and other components that are regularly included with an application. Current development best practices include the concept of “shifting left,” which incorporates the goal of detecting issues as early as possible in the development process.

Catching bugs early in the development process means fewer bugs in the published solution. Each bug that doesn’t make it to production is a vulnerability that is never exposed. This approach earns bonus points because catching bugs early is proven to greatly reduce the cost of each fix.

Shifting left involves integrating functionality testing and vulnerability scanning into multiple parts of the development process. Accomplishing this efficiently requires automation of these tasks. Practically automating these tasks means that a digital solution will need to examine an organization’s source code and look for problems.

It is easy to understand why the idea of an application examining the corporate crown jewels could be a source of worry. The idea that these applications might also communicate with another organization’s network for any reason rationally deepens this anxiety.

Producing quality applications with the minimum possible number of vulnerabilities, however, requires at least some cloud integration. In order for applications that examine source code to do so effectively, they need to have up-to-date information about the latest vulnerabilities. That information is going to come from the cloud.

Basic Cloud Integration Benefits

Among the benefits of cloud computing is the ability to outsource IT operations. Cloud service providers offer everything from basic IT infrastructure to fully configured applications available in seconds, usually configured securely by default. While this benefit is most frequently cited as a means to save money, outsourcing to specialists can result in a level of functionality that is otherwise infeasible.

Solutions that manage the integration of open source components into applications are an excellent example. A dedicated vendor providing this service can hire more staff to solve the problem of identifying and remediating vulnerable components than any individual organization or open source solution could afford.

Consider the “simple” task of creating a list of known vulnerabilities. Simple solutions track only the open source NVD database for vulnerabilities. A top-of-the-line commercial solution, however, would incorporate data from multiple sources. Combining data from the NVD, various security advisories, the GitHub issue tracker, and the bug trackers of individual open source projects makes it possible to more than double the number of security vulnerabilities under consideration.

At a bare minimum, then, applications helping developers shift left will need to contact the cloud regularly to pull down an updated list of vulnerabilities. Anything else is simply impractical.

Consider the programming language coverage of available solutions. In-house and non-commercial solutions are traditionally limited in the number of programming languages they will monitor, and may even be limited to scanning compiled binaries to see if they match the hashes of known vulnerable components.

Top commercial offerings in this space offer detection of vulnerabilities in both binary and source code, identify transitive dependencies, and can scan dozens of programming languages. They also offer support for a much wider range of repositories, build tools, and CI servers.

Support for programming languages and development infrastructure solutions not currently in use can seem superfluous at first. However, multi-language development processes are becoming increasingly popular. Microservices are regularly developed and maintained by different groups of developers, each with their own specialty, and different languages are better suited for different roles. Having vulnerability assessment capabilities that extend beyond what’s in current use allows organizations to easily adapt to change, as well as take advantage of a more diverse skills base.

These features allow for more complete integration with the development processes, giving commercial offerings the ability to examine code based on actual usage instead of relying on a human being to maintain a manifest.

The above are just some of the benefits provided by using a commercial open source component management solution that regularly pulls professionally curated lists of vulnerabilities from the cloud. The benefits are clear and the risk of this level of cloud integration is functionally non-existent.

While it is rare to see anxiety manifest over such basic cloud integration, anxieties do occur. Despite the additional benefits it provides, cloud integration does complicate risk assessments.

There are lots of cloud apps where one could easily imagine a horror story involving the loss of critical business data. They happen quite publicly on a regular basis. Fortunately, it is entirely possible to design a cloud-integrated component management solution such that it presents no real risk.

Mend is committed to ensuring that its products pose no risk of data exposure to customers, a job made much easier by the limited information exchange required to provide a functional, cloud-integrated open source component management solution. The solution is capable of monitoring the customer’s products utilizing the digital signatures as a form of identification for the components, negating the need for sifting through snippet scans that could expose the code to unnecessary risk.

Deeper Integration

Alerting is an example of where cloud integration can get complicated. Alerting is frequently considered to be a critical component of any IT solution. There is little point in detecting vulnerabilities if the application doing so has no means to tell anyone about it!

Alerting could hypothetically be done using only on-premises communications methods. However, in the real world, communications became inextricable from cloud solutions many years ago. Communicating effectively with IT practitioners who can remediate detected issues usually means keeping up-to-date with how those IT practitioners communicate. The shift over time from email to instant messaging, and then to team-based, collaborative tools like Slack is a great example.

Commercial solutions build connectivity to the communications methods requested by their customer base. This functionality only has to be built once for each new communication method and it is available to everyone, but adding this functionality isn’t without cost.

Every third party integration — be that with a communications service or a vulnerability database — needs maintenance. Third-party APIs evolve over time, and someone has to regularly update this functionality.

Third-party integrations also need to be developed with care and consideration for information being passed between solutions. If vulnerabilities in open source components are announced to a development team’s Slack for example, then one should bear in mind that this information is visible to the developers of the Slack service, every member logged into the relevant Slack channel (including potentially all future members of that channel), as well as the developers of any additional third-party solutions that also integrate with Slack.

While it is highly unlikely that information about which versions of various open source libraries are in use by an organization will be data-mined by a rogue Slack integration, it is still possible. Some organizations in highly regulated environments may need to be aware of and document this potential path for information exposure for auditing purposes.

Of course, a commercial vendor building a product gets feedback from multiple customers. If one customer has a concern regarding the previously discussed Slack integration, then a filtering solution designed to restrict information bound for that communications channel could be made available to all customers.

Collective paranoia creates a more secure solution than any individual organization’s security team alone.

Cloud Integration Checklist

At the core of any discussion about the risks of cloud computing is trust. As soon as any form of data is made available to another network, care and consideration need to be applied to determining if that data exposure constitutes a risk. If so, quantifying the risk is a priority.

Questions that need to be asked for assessing your risk include understanding:

1) What data is exposed? An alert that says “three instances of library X, version Y were detected and updated to version Z” could be considered metadata. No actual source code is ever exposed. Real data about the organization trade secrets or business practices is never exposed. The difference could impact not only how easy it is to trust different vendors in the chain, but may affect the regulatory compliance of the solution.

2) How important is the exposed data? The basic cloud integration discussed above exposed only a regular request for up-to-date vulnerability databases. The deeper integration, however, potentially exposes information about individual component use and/or vulnerabilities.

3) To whom is the data exposed? If all third-party organizations that might potentially be able to read exposed data are trusted, then risk is minimal.

4) Do the third parties that have access to this data expose that data to anyone else? When you trust a cloud service provider, you also trust every vendor that they trust. This chain of trust has real-world implications in regulations like the EU’s upcoming General Data Protection Regulation (GDPR).

5) Is the application a traditional SaaS application, or a hybrid? Many SaaS applications store data in the public cloud. In subscribing to the application, organizations gain the benefit of all IT operations aspects being dealt with by the SaaS application provider. In this case, trust is imperative. Hybrid SaaS applications, however, may use an on-premises agent or appliance. These solutions can often restrict the processing of sensitive data to the on-premises agent, and exchange only metadata with the public cloud instance.

Summary

The risks posed by cloud-integrated solutions center on how data is handled. Basic cloud integration is clearly possible without exposing any meaningful data. Deeper integrations can require examination of trust chains, but potential risks posed by more complete data exchanges with cloud-delivered solutions can be mitigated via careful design.

On-premises-only data handling requirements are increasingly rare. Fortunately, even an organization’s most critical data can be safely used in conjunction with public, cloud-provided solutions, provided adequate care is taken to quantify data exposure scenarios.

Cloud-integrated services are more than just a means to outsource IT operations. They offer organizations the benefits of collective intelligence, integration, and interconnectivity in real-time.