Shortcomings of DevOps automation and security bug detection

Jim Manico: The things that really concern me are the risks against Java and Java is being attacked. To a lot of developers, to be honest with you, this is esoteric stuff. So it’s not necessarily the most exciting or sexy feature of Java, but I daresay it’s the necessary stuff. Like for example, there’s a new JSR that addresses serialization and tries to allow for direct white list filtering of exact classes at multiple tiers within your Java application. This is not exciting stuff, right? But it’s necessary to have a secure Java application or at least it gives you a way to address known Java risks. But, you know, it’s not sexy; But it’s important.

Avoiding Java security bugs

Cameron McKenzie: Quite often, the enterprise Java developer just focuses on fulfilling the business requirements and doesn’t really concern themselves about some security implications of the code that they’re writing. For some of the code the developer would write on an everyday kind of basis, what are some of the security concerns they should be taking into account in order to avoid Java security bugs from finding their way into the code?

Jim Manico: Sometimes the use of numerics for financial processing is a lot more tricky than people would expect. Now other problems range from, when you’re using older school Java technologies and you wanna provide certain kinds of controls, like escaping, to stop cross-site scripting, that’s not part of the core language. There’s some parts of it in J2EE, there’s some frameworks that provide it, but it’s not in the core of the language. And it’s a control that I think should be made more readily available to the developer.

There’s also the issue of all the cryptographic APIs. I think some of the best cryptographic APIs are not in the core of Java. They’re in different places like Google projects. Google Tink is a new project. It’s a cryptographic API that makes Java’s world, the Java developer’s world of interacting with low-level cryptographic APIs easier. I’d love to see more of those kind of APIs closer to the core. Let me rephrase that. The closer these APIs are to the core language, the more likely we’re gonna get use from the developers, right?

We’re all Java security engineers

Cameron McKenzie: Now I’m paraphrasing you a bit here, so correct me if I’m wrong. But in one of the previous sessions of yours that I attended, I remember you talking about how you felt that software developers and DevOps people should actually consider themselves security engineersnowadays. What exactly did you mean by that?

Jim Manico: You know, the world’s changing. So I challenge that most developers, whether they believe it or not, whether they think it or not, or whether they even do it or not, they’re security engineers now. Because the code that they’re writing is on the front-lines of protecting organizations from data loss, financial damage, reputation damage, privacy violations, compliance regulations and fines. So these developers and the code they write are on the front-line of all those issues and more. And so they’re security engineers. So it’s a matter of if they’re gonna do it or not. And if you beat a developer over a head with like pen tests and having some security teams run tools, and, you know, especially early in the maturity, training the developers to attack their code really will help change things.

Later on in the maturity, developers are part of conversations at the early part of design, with existing security libraries and knowledge and controls in place, like rigorous authentication and access control services and advanced cryptographic services available to developers. And these are controls at very early stages of designing software; that’s the ideal, right? But at first, if you’re at the early stage of maturity and maybe you haven’t done application security in your organization ever before, then I think a lot of assessment just to see initially where developers are, show them exploits against their software, that’s usually a good way early on to help shake up a culture. But you know, we wanna do this way more proactively, as we get better at writing secure software.

The limits of DevOps based security

Cameron McKenzie: Does DevOps change the software security game? How do you feel about DevSecOps?

Jim Manico: It’s a piece of the puzzle.

I think it’s a nice word but the concept is that we’re automating all aspects of the software development life cycle. Like we’re automating the build process, we’ve done that a lot of times. We’re integrating the security tests into the build life cycle at different phases of building and deploying software. We’re automating. What else we are we doing? We’re automating dynamic tests, we’re automating code skin tests, we’re automating deployment of software. And as we deploy software, we run this huge batch of tests, automated unit tests and dynamic tests and static tests against our code looking for security bugs. Maybe we find security bugs, we’re gonna stop the build and not allow that code to be deployed. Maybe it’s just a warning and we ship it anyways. There’s many gradients how we do that automation.

DevOps also talks about automating, you know, different dashboards and alerts, so people who are monitoring the application real-time get better intel on security when it’s happening. These are things we’ve done for a long time in software. I think DevOps is putting a little more rigor around it, putting a nice name in front of it, and trying to, at least from my world, add more security to it as much automation as possible.

Now the other side to that is there are some elements of application security that don’t translate really well to automation. Like, especially if like, if you wanna look at a turnkey tool, it’s not always great at finding access control problems, or business logic problems, or deeper problems that maybe a pen test would find, that a turnkey tool, especially a tool that’s tuned to work fast in a DevOps environment, you know, maybe a pentester will find that manually where automation may miss the problem. The dark side of DevOps is that we still need people. We can’t just automate everything. We still need people involved at some level of a deep review, I think, to really provide deeper security assurance, if that’s what you want.

Cameron McKenzie: Now tell me honestly, is the deprecation of the Java Web Browser Plug-in the greatest thing to happen to security analysts?

Jim Manico: As a programmer, I’m like, “whatever,” but as an infrastructure person who’s trying to manage a fleet of PCs or Macs or whatnot to keep an organization secure, not supporting that is usually a good thing, right? I don’t wanna trash Java but Java in the client traditionally has not been a great thing. A lot of policies are to heavily limit how Java runs on the client. And so this is one kick in that direction, which is nice. I’m not saying Java-client is bad, it’s just…it’s good for administrators that can do as much as possible to control clients’ JVMs as much as they can. And having rogue applets from any website just running the browser and similar technology just is not an ideal situation, right? So we wanna restrict that and manage that as best as we can.

Software security tooling

Cameron McKenzie: Now when you’re working as a security consultant and you go into an organization, what are some of the tools and the governance models and the policies that you like to see already in place as soon as you get in there?

Jim Manico: So it’s like a good authentication service is usually a good idea, right? So for a developer, especially as your organization matures, it’s really…rather than having every developer recode in some way parts of an authentication service, having or using a rigorous one that all developers can use in a standard way makes that front gate of your application easier to lock down. And the second layer I look at is, of course, access control. Having a good access control service and series of methodologies and database driven rules and configuration capability, all that good stuff for really good horizontal, detailed, permission-level access control in a way that all developers of your team can leverage, that’s a good idea.

You know, we also wanna be able to build user interfaces in a secured fashion. Whatever framework that we’re using, we wanna understand how to keep that locked down via scripting. And we also wanna make sure developers understand, you know, what’s proper data flow through a client, what we should and should not be storing on a client long term. What kind of logic should and should not run on a client? What stuff should we push more server side? What shouldn’t we even do on the client? You know, how are we relating data access and user interface functionality access with the same consistent set of access control rules on both the client and the server?

You know, all these things are things that developers do day in and day out that they really need to understand how to use and get right. And if we don’t have these tools available, if we’re like, “Yo, developer, you know, welcome to the team, go figure out access control now,” you know, good luck with that. You know, that’s so critical of an area of your software, it’s not something you can just…it’s not something you…it’s something you can but I daresay it’s something you shouldn’t just casually put into your application. It should be extremely intentional.

Cameron McKenzie: And, you know, there are a whole bunch of hot topics rising in the Java ecosystem. There’s lots of talk about containers and microservices and coding. But security is important. And if you wanna learn about security, there’s no better speaker to learn from then Jim Mancio.