Securing the JVM

Consider a Java application in a private banking system. A new network administrator is hired, and while going around, he notices that the app is making network calls to an unknown external endpoint. After some investigation, it’s found that this app has been sending confidential data to a competitor (or a state, or hackers, whatever) for years.<br /> This is awkward. Especially since it could have been avoided. Code reviews are good to improve the hardening of an application, but what if the malicious code was planted purposely?<br /> Some code buried in a commit could extract code from binary content, compile it on the fly, and then execute the code in the same JVM run… By default, the JVM is not secured! Securing the JVM for a non-trivial application is complex and time-consuming but the risks of not securing it could be disastrous. In this talk, I’ll show some of the things you could do in an unsecured JVM. I’ll also explain the basics of securing it, and finally demo a working process on how to do it. **Who should attend this talk:** Any developer/ops who is interested about security - you don't need (or want) to be a security expert. **Academic level:** I'll go through the basics, so introductory/intermediate. **What is the take away in this talk:** The JVM allows a lot. Your application doesn't need every feature. You should reduce the attack surface of your application by using the Security Manager (least principle privilege).