May 22, 2018
D2iQ
D2iQ
7 min read
Welcome to part 5 in our series about how DC/OS helps you run traditional Java EE applications on on any infrastructure with reduced cost, improved operations and security, and provides a self-service deployment environment. In this blog post, we'll cover how DC/OS enhances security for Java EE apps with improved application and library patching, secrets management, and privilege management.
Java EE Apps Are At Risk
Heightened awareness of security risks has drawn application security to the forefront in many enterprises. Improving application security is challenging because you can set coding policies for developers and build defense-in-depth strategies, and still fall victim to an attack that exploits a single unpatched library. In particular, industry reports paint a strikingly similar picture of Java EE security from year to year. Veracode's State of Software Security 2017 reports that most open source components remain unpatched once they're built into software and 88% of Java applications had at least one flaw in a component. Yet, only 28% of organizations do any kind of regular composition analysis to understand which components are built into their apps. Given that two-thirds of organizations don't even know what in their Java code, it's easy to understand why so much of it goes unpatched.
Getting Java EE security wrong presents grave consequences. In September 2017, Equifax announced that they had exposed the personal information (names, social security numbers, birth dates, addresses) of over 148 million US customers. The data breaches, which occurred throughout May, June, and July of 2017, were a direct result of Equifax's failure to patch Apache Struts vulnerability CVE-2017-5638, first reported in March 2017, that allowed attackers to execute arbitrary commands on the web server. The CEO, CIO and CSO retired in the wake of the breach, and the company lost about $6 billion in stock value in a week. In May 2018, Equifax's new CEO continues to struggle to regain the market's trust, while the company plans to invest $275 million this year to upgrade security, approximately one-third of Equifax's net 2017 income.
Surely, Equifax must have taken reasonable precautions to secure their infrastructure and applications. The company had a process in place to patch vulnerable libraries, but it proved too cumbersome to test and deploy the new patch before the vulnerability could be exploited.
Despite a never-ending race to patch vulnerabilities before they can be exploited, there are over three billion devices currently running on Java, the most popular programming language over the last 15 years. Java's success stems from its power as an object-oriented programming language that allows development shops to reuse considerable amounts of code. With roughly 90 percent of Fortune 500 companies using Java, IT leaders must figure out how to offset the language's risks in order to benefit from its power.
DC/OS Secures Java EE Apps
Fortunately, DC/OS provides platform-level features that alleviate many of the security concerns that have troubled Java EE administrators from the beginning, and minimizes the burden of security management through sophisticated automation and high-availability features.
Fixing Java's inherent security flaws is a massive undertaking that has been in progress on a global scale for about 20 years. Rather than rewrite Java EE, a better strategy is to reduce the attack surface and increase the use of automation to maintain high availability. DC/OS takes care of this for you with three powerful mechanisms:
- Application and Library Patching in a High Availability Environment
- Secrets Management
- Application Privilege Management
Application And Library Patching in a High Availability Environment
Java admins face a steady stream of patch-related challenges in order to secure applications and platforms. Solving these challenges requires an array of tools to scan libraries and code (both deployed and in centralized repositories), and a simplified application deployment and update process.
With datacenters relying on many thousands of physical and virtual servers to run Java EE apps, the environment can rapidly spiral out of control. As a result, many admins have simply given up and stopped patching, leaving the door wide open to attackers to go after known vulnerabilities.
Simplify and Automate Java EE App Deployment and Updates
Managing patches for applications, libraries, and underlying software requires constant vigilance - and even then it's impossible to have every version of every piece of the multilayer puzzle be up-to-date across an entire enterprise. Without simplification and automation this onerous task quickly spirals out of control, causing operators to fall behind and opening the door to attackers.
IT organizations running Java EE applications on DC/OS can deploy patches to libraries and code directly using the CLI or UI, or use the API to integrate with a CI/CD environment. DC/OS helps you patch production environments with zero downtime by using non-disruptive rolling restarts. The newly patched Java EE app will launch and become operational before DC/OS shuts down the unpatched version.
Java EE Security in DevOps Requires Support for an Ecosystem of Tools
Developing, testing, and applying patches via an automated CI/CD tool can substantially reduce the amount of time needed to fix security issues by verifying that patches won't break existing code when deployed. No matter how efficient DevOps practices are and how automated DevOps tools are, patches still require code review (automated and/or manual) and QA testing (automated and/or manual) so they don't introduce a new set of bugs.
DC/OS integrates with your CI/CD pipeline, including with package scanning tools such as JFrog Xray or Nexus Lifecycle Manager for artifact analysis.
Secrets (Password) Management
The Java world runs on sensitive information that is difficult to secure, like static passwords, configuration files, and certificates. For example, countless Java EE apps are secured using passwords set in configuration files. Developers learn these passwords while performing general maintenance and emergency debugging of applications. Passwords coded into files are almost never changed, representing a security gap that can go on for years.
Compounding this is that access to shared resources (such as databases) is typically provided to Java apps via shared credentials. Many of these credentials are stored and transmitted in clear text, making them vulnerable to discovery. However, in many organizations, changing a single database password can result in having to change the statically defined password for hundreds of Java EE apps. Most passwords for resources such as databases rarely get changed because this would require an application restart and an outage.
In order to alleviate this burden, Mesosphere DC/OS includes a centralized encrypted and access-controlled secrets management store, and a simple and automated way to enroll or generate these secrets. DC/OS enforces access control when developers and Java EE apps request secrets such as credentials, confidential files, and certificates.
Passwords for application resources can be changed without downtime. You can add a new password for the application resource (leaving the old password temporarily in place), change the secrets definition to the new password, and then update the service with the new password. This methodology can also be used to frequently change the resource passwords to prevent reliance on a commonly known password.
Restricted App Privilege
Any good security administrator knows the importance of keeping systems safe by relying on the principle of least privilege. Every application, library, and user should operate using the least set of privileges necessary to complete their particular task. Executing with minimal privileges mitigates against exploitation in the event that a vulnerability exists in the code.
Any good developer knows that those carefully planned least privileges are most certainly the cause of crashing code. For this reason, there are far too many Java EE apps running at far too many enterprises with excess privileges. This is the kind of nightmare that keeps operators awake at night.
DC/OS operators enjoy a full night's sleep because the platform runs all services and containers with least privilege by default. DC/OS launches application with the nobody user, the lowest level user in Linux, even lower than guest. Launching applications with nobody limits privilege escalation attacks automatically and greatly reduces the attack surface for your Java EE applications.
DC/OS Solves Java EE Security Nightmares
DC/OS automates and secures traditional Java EE applications in a scalable and high performance manner. Organizations now have a single platform for running traditional apps, Docker containers and stateful data services on any public or private infrastructure. Having a single, production proven, platform increases resource utilization, simplifies application architecture, and accelerates introduction of new technologies.
