The latest cloud infrastructure announcements, technical solutions, and enterprise cloud insights.

Tools for improving cloud security posture management while maintaining privacy

Maywun Wong
Director, Product Marketing
This is a syndicated post, view the original post here

 Contributed by: Jay Bretzmann, IDC Program Director, Security Products 

Whether your organization lifts and shifts or develops a cloud-native application, the challenges of these new infrastructures are nothing short of daunting. Cloud environments are new to most and present the most complex configuration requirements of any former IT environment. Credential theft has led the list of most popular attack vectors for years, but may be shortly supplanted by cloud deployment misconfigurations. A well-designed Cloud Security Posture Management (CSPM) tool will provide automation at scale.

There are typically thousands of settings to be configured and maintained when defining a new IaaS environment. Some of the more typical mistakes include: defining overly permissive security access policies, providing open access to unencrypted storage buckets, unsecured internet connectivity paths, improperly configured virtualized network functions, and more not to mention dozens of application-specific settings per each defined instance.

Honestly, mistakes are easy. Many configuration mistakes are made in development by well-meaning applications developers. Open storage buckets may facilitate application construction and collaboration in development with the intention of fixing the issue at deployment. Frankly, it is easy to miss a setting or forget to change a configuration given the sophistication of today's applications. It's almost an impossible task for most organizations. But, according to the cloud security shared-responsibility model, security in the cloud is on the shoulders of the application developers.

Oracle Cloud Guard is the initiative of Oracle Cloud Infrastructure (OCI) to help customers identify, analyze, and remediate their defined tenants and compartments. Think of it as a toolbox of tools to help save us from ourselves. Oracle Cloud Guard applies Oracle expertise in the form of pre-defined recipes, which are something akin to actionable best practices Oracle has developed from running its own business with OCI. If you wanted to fix your automobile, the dealer that sold you the car might be a great place to start; this is the same concept.

Here's one of the best qualities—nothing's set in stone. Oracle never sees its customers’ tenant definitions and data, helping ensure privacy. Oracle developed Oracle Cloud Guard to be ultimately customizable. The recipes provided are a (very good) starting point, but tenant security teams can modify where they run and how they operate. Oracle Cloud Guard is essentially a toolbox given to cloud tenants; Oracle cannot see how the tenant is using the tools in the privacy of their own environments.

IDC believes another unique and useful feature is the ability to dismiss a detected condition rather than forcing the application of some immediate fix. This can be because the situation represents a low-risk exposure, a lack of currently available resources, or a need to further investigate the problem or recruit additional analytical skills. But just because something's dismissed does not mean the condition will go away. You probably will want to address the issue, but you may not want to do it immediately. The dismissed detection will resurface with the next run of log scans and remind the operator that something is still amiss (like a nagging seatbelt alarm in any late model automobile). The design principal here was to the make the security team fix the rule triggering the event or fix the problem—just maybe not today.

Oracle Cloud Guard runs within defined targets that at present are logical compartments within defined IaaS tenants. Future releases will begin to support and operate within application environments as well again providing Oracle developed expertise across many of its "digital properties" or Oracle-owned SaaS applications. Within a target, customers run two types of recipes, detectors and responders, to identify and remediate problems. There are two currently defined detector recipes and two defined responders:

        - Configuration Detector – a set of configured rules for discovering configurational problems
        - Activity Detector – a set of configured rules for revealing suspicious activity patterns

Both detectors are freely provided resources. There are many more in the works and some of the more specialized and difficult to develop detectors may be chargeable (but optional) Oracle Cloud Guard components.

Like detectors, Cloud Guard provides an Oracle-managed recipe for responders. Users can clone these recipes to create and apply a customized set of responders (below) for integrating with third-party apps such as Slack, PagerDuty or any other defined APIs.

        - Notification Responder – issues problem details to Oracle Cloud Infrastructure Events Service
        - Remediation responder – takes an action against a problem using OCI Notifications or OCI Functions

Detector recipes are triggered within Oracle Cloud Guard by audit log entries that kick-off an OCI Event so it's always on by default. In the case where someone opens a new storage bucket, the configuration detector is notified in short order—within approximately five minutes—and a new scan is run on just that one bucket. This keeps Cloud Guard's status up-to-date without taxing tenant resources with unnecessary, repetitive scanning all in near real time.

Clearly, there's a pretty black-and-white case for organizations to deploy a CSPM solution to help them understand and control their public cloud infrastructures, but why is one better than another? Most solutions were built to scale and most string together log events and other security intelligence data providing insights and recommendations for fixing mistakes that humans are just going to make. Most also work across multiple cloud platforms because few organizations are running just one cloud infrastructure.

As a later player in the game, OCI has some catching-up to do, but the challenge is one of writing an application on top of a database and the company has some experience in that area. IDC believes there are several good reasons why CISOs should be running Oracle Cloud Guard on OCI:

        - It covers 90% of near-term use cases.
        - It was built by the people who know the most about OCI, the developers of OCI.
        - It's run by the OCI security team, using the tools and constantly improving the tools.
        - And it’s free.

In another year, Oracle Cloud Guard will be a more capable product and provide additional and expanded recipes for helping OCI customers configure and manage much more than just an IaaS environment. Expansions to the currently-free detectors are also set to be free. Oracle-managed recipes for its SaaS offerings will provide that same hands-on expertise developed by a company that entrusts its daily business to its own IT solutions that are becoming more autonomous with each passing year.

I invite you to read more about IDC’s analysis of the security of Oracle Cloud Infrastructure in the IDC Lab Validation, “Putting Tenant Data Safety and Privacy First with Automated Operations.”

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha