Frictionless Cloud-Native Security

Amitpal Singh Dhillon
6 min readAug 17, 2021

How could we boost performance, enhance usability while improving the application security posture? These are key areas of concern and business opportunity as customers launch the next generation of super apps for fintech, health tech, and 5G in a sustainable ecosystem.

We have used GraalVM, Micronaut VSCode extensions, and Oracle Cloud Infrastructure to show an out-of-the-box workflow for securing applications during the build and runtime phases.

Photo by Tina Rolf on Unsplash A Frictionless Cloud Native approach

Application Defense via Sandboxing

a) Computer programs access system memory for processing.

  • Humans draw upon stored memory to perform daily tasks.
  • When a computer program tries to access a piece of memory that doesn’t exist or otherwise access memory the wrong way, it may crash.

— > We call this a memory access violation (illegal pointer access), also called a segmentation fault (or segfault)

GraalVM Enterprise has the ability to run C code in a managed mode, in this mode, memory violations by user code are reported as exceptions instead of crashing the VM.

Figure 1: GraalVM catches and prevents memory access violations

b) Computer programs are often unable to catch unsafe practices such as accessing arrays (data structures) outside of the bounds.

At times there is no check to determine whether an array index is out of bounds. During program execution, an out-of-bounds array index can cause serious problems.

— > GraalVM Enterprise has the ability to catch the out-of-bounds access and throws an exception, this does not just prevent crashes, it can also prevent more subtle bugs. A proper exception that can be handled and leaves the system in a consistent state instead of overwriting random memory.

Figure 2: GraalVM catches the out-of-bounds access and prevents crashes

In addition, GraalVM Enterprise has the ability to enforce application access restrictions via safe resource limits. This ensures the safer execution of applications on the JVM with resource limits and execution control.

c) Limit the active CPU time

The sandbox.MaxCPUTime option allows you to specify the maximum CPU time spent running the application. There is a sample polyglot program below written in java and javascript that shows this in action.

Figure 3: Max CPU time limit is exceeded and prevented.

d) Limiting the number of executed statements

The sandbox.MaxStatements option specifies the maximum number of statements an application may execute.

Figure 4: Max Statements limit is exceeded and closed.

These capabilities are available in GraalVM Enterprise providing an organization, fine-grained access control of their applications to give better protection against external threats (e.g. illegal pointer access and buffer overflow violations) managed in a sandbox plus the ability to enforce resource limits (e.g. number of statements and CPU time-boxed constraints) to give the best chance of addressing the full attack continuum: before, during, and after the attack.

GraalVM Enterprise Edition enhances your application security by addressing some of the common sources of vulnerabilities. For instance, most real-world applications today running on languages such as Python, JavaScript or Java include native libraries for performance reasons, however, these native libraries form a back door for security vulnerabilities. GraalVM minimizes your application attack surface both on-premises and in the cloud by running these native libraries in a “safe mode”. In the safe mode, languages are compiled using features such as managed memory, garbage collection, and bounds-checks, which help prevent common security vulnerabilities such as buffer overflows.

NetSuite uses the GraalVM platform to contain customer-provided SuiteScript, thereby reducing the risk from third-party code

Speeding up Authentication

Faster standards-based Authentication powered by Micronaut and GraalVM Native Image. Fast logons give a better user experience in fact. User expectations have changed, and slow is unacceptable now. 40% of customers abandon a webpage if it takes more than 3 seconds to load

Now, can secure Micronaut applications using okta oauth2.0 integration.

Figure 5: Micronaut Application Secure Flow with OAuth2 standard

Here is an example of how this setup looks like within an IDE when setting up a cloud-native application with performance and security. There is a wizard-based setup that includes out of the box security configurations, for JWT, LDAP, SAML, OAuth2, Session management, Token propagation, security rules (IP Pattern Rule, Secured Annotation, Intercept URL Map, and Built-In Endpoints Security)

Figure 6: Out of the box Micronaut security configurations

And here is an example in action showing integration with Okta via OAuth with the speed up of authentication down to a split second.

Figure 7: Authentication speedup and performance improvements

Container Security

Minimize application attack surfaces in your data center and in the cloud. This can be achieved by using minimal docker images that pull only required dependencies. There are several benefits, smaller container images (save disk, with faster download) and remove binaries/shared libraries that can be executed by an attacker.

With GraalVM native image, sizes can be as little as 11Mib for a Java application. Let's use a sample java application

public class Main {
public static void main(String[] args) {
System.out.println("Hello from GraalVM");
}
}

Compile:

javac Main.java

For real applications, create a jar for Main.class

jar --create --file=app.jar --main-class=Main  Main.class

Let's build this and check its size, it is now ~11MB. And there you have it. Java in a container with an 11MB image.

[opc@instance-20201214-2208 dockersec]$ native-image --static -jar ./app.jar -H:Name=output[output:11731]    classlist:   3,409.28 ms,  0.96 GB     [output:11731]        (cap):     753.88 ms,  0.96 GB   [output:11731]        setup:   5,107.40 ms,  0.96 GB.  [output:11731]     (clinit):     267.78 ms,  1.70 GB.  [output:11731]   (typeflow):  10,191.03 ms,  1.70 GB.  [output:11731]    (objects):   9,921.73 ms,  1.70 GB.  [output:11731]   (features):     452.06 ms,  1.70 GB.  [output:11731]     analysis:  21,150.32 ms,  1.70 GB.  [output:11731]     universe:     759.97 ms,  1.70 GB.  [output:11731]      (parse):   3,641.59 ms,  1.71 GB.  [output:11731]     (inline):   3,686.46 ms,  2.25 GB.  [output:11731]    (compile):  46,031.42 ms,  4.55 GB.  [output:11731]      compile:  54,442.77 ms,  4.55 GB.  [output:11731]        image:   2,524.20 ms,  4.55 GB.  [output:11731]        write:     391.80 ms,  4.55 GB   [output:11731]      [total]:  88,098.28 ms,  4.55 GB
# Printing build artifacts to: output.build_artifacts.txt.

And run docker build for scratch:

[opc@instance-20201214–2208 dockersec]$ docker build . -t scratch-graalSending build context to Docker daemon 11.22MB                   Step 1/3 : FROM scratch                                             — ->                                                             Step 2/3 : COPY output /opt/output                                  — -> 732af31a7d5d                                                 Step 3/3 : CMD [“/opt/output”]                                       — -> Running in c00fca909935                                    Removing intermediate container c00fca909935                        — -> ece953240c73Successfully built ece953240c73                              Successfully tagged scratch-graal:latest[opc@instance-20201214–2208 dockersec]$ docker images | grep scratch-graalscratch-graal latest ece953240c73 9 minutes ago 11.2MB

compared to running it on your own OS, using the scratch image with the native image is almost 10x smaller at 11.2MB

debian-graal latest 8d09b5abe539 15 minutes ago 81.6MB

With the reduced attack surface as we see in the details below.

Figure 8: Reduced attack surface

Summary

This helps to enhance your desktop application security while reducing business risks. Reduce risk by packaging third-party or native code in GraalVM containers. Other use cases include sensitive apps that can only run within the realm of a desktop and its web browser or Air gapped from the internet or any server as native isolates.

--

--

Amitpal Singh Dhillon

vCISO, previously, from Oracle Inc, Sourcefire, Cisco Systems, and Applied Materials.