Waratek, application security for Java! A technical overview! © Copyright 2014 !

Copyright 2014 Waratek Ltd.!

Proprietary Information !

Who am I?! Nigel Daniels! •  Wide range of tech roles including robotics, process control, network management, 3D visualization, media and enterprise software.! •  8 years with IBM developing, delivering and product managing WebSphere brand products.! •  Consulting on software product management and delivery.! •  Product Manager with Waratek for 2 years.! © Copyright 2014 !

Proprietary Information !

What will we cover?! •  •  •  • 

What is the Waratek JVM?! What do we mean by securing Java applications?! What other capabilities does this bring?! Q/A!

© Copyright 2014 !

Proprietary Information !

What is the Waratek JVM?!

THE WARATEK JVM! © Copyright 2014 !

Proprietary Information !

Java Virtual Containers! •  The Waratek JVM is a virtualizing Java Virtual Machine that creates Java Virtual Containers.! JVC-1! JVC-2! JVC-3! •  A Java Virtual Container is an isolated, fully TCK compliant abstraction of the underlying JVM.! •  We license technology from Oracle Waratek JVM! and add our own JIT extensions.! •  The containers have elastic resources that can be changed at runtime. Resources such as memory, CPU, bandwidth and file I/O.! •  All of the container resources can be metered for billing.! © Copyright 2014 !

Proprietary Information !

The JVM components! JVC-1!

JVC-2!

JVC-3!

JVC-…!

JVC-64!

JAR!

JAR!

JAR!

JAR!

JAR!

Fully isolated, controlled and monitored via the hypervisor.!

DOM-0!

Waratek Hypervisor!

© Copyright 2014 !

JVCs!

Users can extend capability here via the Java Virtualisation Interface (JVI).!

GC!

JIT Compiler!

Class Lib!

G1GC!

DRL V2.0!

Java SE n!

JVM ! Standard components although the JIT compiler heritage is Intel based.!

Proprietary Information !

Types of virtualization! Guest OS!

© Copyright 2014 !

Guest OS!

Hypervisor!

Hypervisor!

Host OS!

Hardware!

Hardware!

Type 1 Virtualization!

Type 2 Virtualization! Proprietary Information !

Type 1 virtualization! Guest OS! Hypervisor! Virtual Machine Monitor!

Trap x86 instruction!

Is it sensitive ?! No!

Yes!

Emulate instruction!

x86 Hardware! © Copyright 2014 !

Proprietary Information !

Problems virtualizing Java! Trap-and-emulating x86 instructions doesn’t work for Java, all JVM instructions are non-sensitive. ! But what about a call like:!

! java.lang.System.exit(int) JavaEE and every other Java application framework uses co-operative multitenancy…! but the last time co-operative multi-tenancy was used was in Windows 3.1 and Mac OS 9 in the 1990’s!! So how do we provide fully isolated virtualization for Java?! © Copyright 2014 !

Proprietary Information !

Java Virtualization! Guest (JVC) Application! JVM Hypervisor! Virtual Virtual Machine Monitor!

Exit transition!

Is the type virtualized ?!

Yes!

Emulate type access!

No!

Host JVM! © Copyright 2014 !

Proprietary Information !

Java Virtual Interface! •  The Waratek hypervisor exposes monitoring and control access via the JVI.! •  This enables:! •  Visibility of all type access! •  Type sharing! •  Type emulation!

•  We already ask about type emulation.! •  Security is a logical next step.! © Copyright 2014 !

Proprietary Information !

Real-time Application Self-Protection (RASP)!

SECURING THE APPLICATION! © Copyright 2014 !

Proprietary Information !

The security landscape! Network!

Application!

Too hot!!

Too cold!!

•  Risks to applications! •  Departmental silos! •  Large amounts of effort!

•  Low knowledge of application logic! •  Data exposure!

! Inside the application?! •  Code reviews! •  Static analysis! •  Team training!

! © Copyright 2014 !

What’s needed? ! An approach that allows you to:! •  get into the application and framework ! •  do so in an operationally and politically viable way!

In the infrastructure?! •  Agent based! •  Intrusion prevention! •  Web & next gen. firewalls!

! Proprietary Information !

The best place to protect Java is in the JVM! Application!

Too hot!!

JVM!

Network!

Just right!!

Too cold!!

! The Virtual Machine (VM) Layer is the sweet-spot for application security! •  •  •  •  • 

It sees every network packet…! …but also sees every CPU instruction! It is transparent to both applications and networks! Makes no changes to application code or network configuration! Leverages industry-standard and certified technologies! “Applications should be capable of self-protection — that is, have protection features built into the application runtime environment.” Gartner!

© Copyright 2014 !

Proprietary Information !

Security benefits!

Application threat monitoring and forensics.!

© Copyright 2014 !

Legacy Java application protection and compliance.!

Proprietary Information !

JVMs themselves are not secure! Java Code!

The JVM itself performs NO security checks.!

Application!

Dependencies!

Security Manager!

JVM! JNI!

C/C++ Code!

© Copyright 2014 !

All enforcement is through the Java API’s and the Security manager levels.! If these are compromised or bypassed then the JVM can be instructed to do ANYTHING.! Calls to JNI libraries are a particular concern as they run directly in the host OS.!

Proprietary Information !

Waratek monitors all activity! Java Code! Waratek Container! Application!

Dependencies!

Security Manager!

Waratek!

JVM! Process Container! JNI!

C/C++ Code!

© Copyright 2014 !

The Waratek layer gets to inspect every call the application and its dependent libraries need to make.! The calls can then be checked against rules, any suspicious behavior is then logged.! We can also isolate untrusted JNI code by isolating the library within its own process container at the OS level.! Simple, single line rule syntax.! Everything is local to the JVM so it is very low latency.! Rule files can be updated live.!

# Example file rules file:read:/etc/:deny:warn file:read:/etc/passwd:allow:warn # Example networks rules network:connect:www.google.com::deny:warn network:accept:localhost::deny:warn # SQLi Mitigation sql:database:oracle:deny:warn

No agents or code updates are required.! Proprietary Information !

Rules cover all application aspects! Language rules:! •  •  •  • 

Class loading – class or package level.! Class linking – any defined class.! Reflection – from variable to package level.! Throwable – exception classes.!

Input Output rules:! •  File – any file I/O.! •  Network – any network I/O.!

Other rules:! •  Native code – accessing JNI.! •  Process forking – starting external processes.!

External attack vectors:! •  SQL injection.!

© Copyright 2014 !

Tooling support makes rule customization simple.! Proprietary Information !

Legacy Java is a large and costly issue! Java versions detected through enterprise endpoints*!

93% of organizations are running Java versions over 5 years old.!

10%!

The average organization has different 51 versions of Java with less than 1% of installed Java is up-to-date.! In 2013 US-CERT/NIST issued over 250+ CVE alerts for Java. One version of Java SE 6 has 96 known ‘perfect 10’ vulnerabilities.! Cost of migration increases with the age of Java! $!

19%!

Other! 1%! 5%!

Java 3.x! Java 4.x! Java 5.x!

13%! 52%!

Java SE 6! Java SE 7!

To migrate apps need to be retested in case they use deprecated methods.! In some cases modules will require rewrites (assuming the code and capability still exists!).!

re-platforming costs!

time! © Copyright 2014 !

Objects persisted in data stores need to be upgraded in sync with the update as well.! *Source: Java Vulnerabilities, Write Once, Pwn Anyware, 2013, Bit9 ! Proprietary Information !

Legacy containers extend application life! This approach to legacy Java has two key advantages, first no changes to the application:! Java SE 5 Container!

•  The application does not see an API change.!

Java SE 1.5 Application!

•  Deprecated calls still function.! Waratek! Java SE 1.7!

•  Serialized objects still function.! •  The application is still using the API it was first tested against.!

SE 1.5 Exploit!

Network!

Second, externally the world can move on:! •  Administration is on an up-to-date SUPPORTED platform.! •  The surrounding infrastructure can be updated.!

© Copyright 2014 !

Proprietary Information !

Managing Java more efficiently than before!

VIRTUALIZATION BENEFITS! © Copyright 2014 !

Proprietary Information !

Infrastructure benefits!

Drive up data center density to drive down operational cost and future capital cost.!

© Copyright 2014 !

Manage application resources live for greater stability and uptime.!

Proprietary Information !

Drives up to x6 density! JBoss 6.1.0!

JBoss 6.1.0!

JBoss 6.1.0!

JVM (1Gb)!

JVM (1Gb)!

JVM (1Gb)!

Server A (4 core/6 Gb)!

Vs! JBoss 6.1.0!

JBoss 6.1.0!

JBoss 6.1.0!

How many more?!

Waratek (3Gb)! Server B (4 core/6 Gb)!

In the client testing outlined above we could achieve a total of 13 JBoss instances (165Mb each) AND have an 850Mb memory pool giving each instance an effective 1Gb memory… a x4.3 density increase.! We have attained up to x6 density in testing, these results have been confirmed by >! Accenture in their labs.! © Copyright 2014 !

Proprietary Information !

Overall System Memory!

Understanding memory density! Heap! Heap! Actual Heap Used!

Heap! Heap! Actual Heap Used!

Perm-Gen!

Perm-Gen!

Code-Cache!

Code-Cache!

JVM-1!

JVM-2! OS Memory!

If I want to change my heap size I need to shutdown and restart!! © Copyright 2014 !

Proprietary Information !

Overall System Memory!

Understanding memory density! JVC-1! Actual Heap Heap! Used!

JVC-2! Heap! Actual Heap Used!

JVC-3! Actual Heap Heap! Used!

Perm-Gen! Code-Cache! Waratek! Linux!

To change the heap here we do it while the application runs.! © Copyright 2014 !

We make heap more efficient! This can also be shared across containers! Some of this can be shared!

Now one JVM, so cost is amortised! Memory consumed by the operating system!

Proprietary Information !

JVM memory is inflexible! JVM4!

358.4!

153.6!

307.2!

JVM3!

204.8! Used!

JVM2!

819.2!

JVM1!

512! 0!

JVM 1! JVM 2! JVM 3! JVM 4! Total!

© Copyright 2014 !

1228.8! 512!

500!

Heap Size! Utilization! 1024! 50%! 2048! 40%! 512! 60%! 512! 70%! 4096!

Free!

1000!

Used! 512! 819.2! 307.2! 358.4! 1996.8!

Free! 512! 1228.8! 204.8! 153.6! 2099.2!

1500!

2000!

2500!

On a single server it is typical to find the following sort of deployment.! ! Note: If the application in JVM 3 needs a further 205m it will crash with an out of memory error, even though JVM 2 has 1228.8m free!! Proprietary Information !

Waratek improves stability! JVC1! JVC1! 512!

JVM1!

JVC2! 819.2!

JVC3! 307.2!

JVC4! 358.4!

JVC2!

Free! 2099.2!

JVC3! JVC4! Free!

0! JVC 1! JVC 2! JVC 3! JVC 4! Free! Total!

© Copyright 2014 !

500! JVM 1! 512! 819.2! 307.2! 358.4! 2099.2! 4096!

1000!

1500!

Effective Max! 2611.2! 2918.4! 2406.4! 2457.6!

2000!

2500!

3000!

3500!

4000!

4500!

On a single Waratek VM without constraining the memory the same 4096m can be used far more effectively.! ! With access to the free memory, each application has a far higher effective memory.!

Proprietary Information !

Elastic resources take density further! JVC 1 20% overhead! JVC1! 512!

JVM1!

JVC2! 819.2!

JVC3! 307.2!

JVC 2 20% overhead! 0! JVC 1! Free! JVC 2! Free! JVC 3! Free! JVC 4! Free! JVC 5*! JVC 6*! Free Pool! Total!

500! JVM 1! 512! 102.4! 819.2! 163.84! 307.2! 61.44! 358.4! 71.68! 512! 512! 675.84!

1000!

JVC1! Free! JVC2! Free! JVC3! Free! JVC4! Free! JVC5! JVC6! Free Pool!

JVC 3 20% overhead! JVC4! 358.4!

JVC5! 512!

JVC6! 512!

Free Pool! 675.84!

JVC 4 20% overhead! 1500!

Effective Max! 1187.84! 1495.04! 983.04! 1034.24! 1187.84! 1187.84!

2000!

2500!

3000!

3500!

4000!

4500!

In this model our four original JVC containers are limited to their current memory needs plus an extra 20% overhead.! ! But all of them share the same 675.84m of elastic memory (the free pool).! ! This allows for two further containers increasing our Java density in the same 4Gb of memory.!

4096!

* New Instances! © Copyright 2014 !

Proprietary Information !

JVC1! 307.2!

JVM1!

0! JVC 1! JVC 2! JVC 3! JVC 4! JVC 5*! JVC 6*! JVC 7*! JVC 8*! Used Pool! Free Pool! Total!

© Copyright 2014 !

JVC2! 491.52!

500! JVM1! 307.2! 491.52! 184.32! 215.04! 512! 395! 512! 256! 798.72! 424.2!

JVC3! 184.32! JVC4! 215.04!

In non-production greater 
 density is possible!

1000!

JVC5! 512!

1500!

Effective Max! 731.4! 915.72! 608.52! 639.24! 936.2! 819.2! 936.2! 680.2!

JVC6! 395!

2000!

JVC7! 512!

2500!

JVC8! 256!

Used Pool! 798.72!

3000!

3500!

Free Pool! 424.2!

4000!

4500!

JVC1! JVC2! JVC3! JVC4! JVC5! JVC6! JVC7! JVC8! Used Pool! Free Pool!

This model takes a much more aggressive approach to the use of elastic memory. Here each application container is only given 60% of what it needs forcing the use of the free memory pool.! ! But now there is enough memory available for four more JVCs this has doubled the Java workload possible on the same machine.!

4096!

Proprietary Information !

Runtime Application Self Protection for Java!

Driving the cost of Java workload down by up to x6!

Waratek!

© Copyright 2014 !

Proprietary Information !

Thank You! Any Questions?!

© Copyright 2014 !

[email protected]!

Proprietary Information !