Treat Security as a Risk

Safety is the poster child for a nonfunctional requirement: Most people don’t care until the proverbial fecal matter hits the rotating propeller. The consequences can range from loss of reputation to legal liability to get the business out. In my post about running unlocked code, I concluded that you should treat security as a risk – and leave it at that. I think it requires a custom function.

Risk management is largely documented. You can find it in many, if not all, engineering disciplines. The risk management process consists of the following steps:

Definition ofanalyzedefine the prioritiestreatsMonitor

Let’s see how we can apply it to security using the Attach API as an example.

hazard identification

In short, the Attach API allows changing a file byte code It’s already loaded into JVM 1.6+ running. Therefore, you need:

  • The running JVM’s PID.
  • Ability to run another JVM on the same system.

When the attached JVM starts again, it ignores the update byte code It downloads the code from the expected location. Thus, there is no trace because the file byte code It has been changed via feature.

With the Attach API, a malicious actor can change the behavior of a running application. For example, a representative can direct a few cents on each transaction to his account in the banking system.

Risk analysis

Now that we have correctly identified the risks, we need to determine the probability of their occurrence: How likely is a harmful factor to provoke the risk?

For example, we need to evaluate the probability of:

  1. access to the system.
  2. Get permissions to start the JVM.
  3. Get the JVM’s PID.

System access and permission depend on factors unknown in the context of this blog post. However, getting the JVM’s PID is easy if you meet the other two.

With JVMs below version 9 we need to default to Runtime class and use jps ordering:

long pid = Runtime.getRuntime()
               .map { it.split(" ").toTypedArray() }
               .filter { it.size > 1 && it[1].endsWith("BusinessApplicationKt") }
               .map { it[0] }

From 9 onwards, the JVM added a file ProcessHandle class in process API:

long pid = ProcessHandle.current().pid()

define the priorities

To prioritize, we need to assess the impact of a successful attack.

In the context of the Attach API, it depends on the target system. It’s very context dependent, so here’s a sampling of some of the areas:

impact size Example
Threat to human life very high
  • dangerous industrial process
  • surgery device
  • hospital
Economical with large radius From high to very high
  • Banking transactions involving millions
  • stock trading
  • food commodity trade
Games (excluding competition) Few candy crush


Treatment includes two separate things:

  • Prevent risks.
  • dilutions, if any.

Mitigations allow to reduce the effect of the attack. There may be many mitigating factors. With each of them, you need to describe: how much to reduce the effect and how much it costs.

With the Attach API, the feature is enabled by default. The treatment is to disable it explicitly. I couldn’t come up with any relief. Once the malicious agent is injected, byte codeThe latter will take its course.

Managing risk in the real world

Security is not a black and white concern. There is no such thing as a secure system versus an unsecure one. Some systems are more secure than others against certain threats. Moreover, improving security against any threat generally has a cost. Hence, one needs to find the right balance between the likelihood and impact of the risk and the cost of treatment and potential mitigation.

If you implement all of the risk management steps I described above, you will likely fail anyway. The reason is that we work within human organizations: it includes politics, blame games, avoidance of responsibility, and such company-related details.

If you want to have any chance of making your risk management work, you need to keep track of the decision that was made. The record should include all of the above: danger, description, probability, impact, mitigation, etc., without forgetting the decision. Maybe AcceptanceAnd to reject, or any mitigating measure.

An important piece of information is missing: the person who made the decision. By having someone responsible, they will be committed and not only included. At this point, there is no guarantee yet. However, the organization will be better equipped to avoid the worst errors such as the Equifax data breach.


Leave a Comment