4 ms·

As a small time hobby / small business server administrator (enthusiast) , what's the best practice here?

• AndrewDucker 4y ago
  Make sure you have the time to patch/update your applications when security issues are raised.
  • LaGrange 4y ago
    Whoa whoa whoa, slow down, that would mean somebody in the organization would have to spend _valuable senior developer time_ on reading things. Yes, that's jaded, but that's what I'd expect. So far I've yet to feel like a job _encouraged me_ to pay attention to security updates, accessibility standards, or anything like that. And it's quite hard to keep myself motivated to do that, when it's pretty clear most software products are disposable anyway.
    • AndrewDucker 4y ago
      You can automate some of this. BlackDuck scans your dependencies (if you're using Maven or similar) to check what versions of dependencies you're using and if there are known CVEs for them. And there are plenty of competitors. But you still need to patch and test when you find out there's an issue.
    • thechao 4y ago
      I hired a guy because he loves to be (technically) correct about everything, and he does so by reading (and REREADING) specs. Gives my team a superpower.
• shagie 4y ago
  Put a dependency check in your builds. Raise build errors when something is bad. Have it build on a regular basis (could be every month)... and then fix things. https://owasp.org/www-project-dependency-check/ https://owasp.org/www-project-dependency-check/ And some examples - https://jeremylong.github.io/DependencyCheck/dependency-check-maven/ https://jeremylong.github.io/DependencyCheck/dependency-chec...
• kevinmgranger 4y ago
  As an alternative / addition to the other suggestions, maintain an internal artifact store that syncs with upstream stores, but enforce that vulnerable versions aren't present. Block access to the upstream artifact stores so builds have to use the internal one.
• mikeweiss 4y ago
  If want an extremely strong mitigating control that you can design into your architecture..... allow internet egress in your production environment only to a list of domains/ips in an allowlist. This or control egress with an explicit proxy. If vulnerable systems have no path to the internet at large then it's extremely difficult for attackers to know if a system is vulnerable to log4j and even harder to actually use it to exfiltrate data.
• brabel 4y ago
  Every case is different... but for the log4shell case in particular: * newer JVM versions protected against the main attack (JNDI), so if you were on any JDK version released in the last couple of years, you wouldn't be vulnerable. * Java serialization filters [1], which are highly recommended to be setup in any Java application, would also have prevented the attacks. * not including large libraries with lots of unused features could have prevented this. In this case, log4j has support for a dozen or so things that should've been opt-in (and I think they are now) but were enabled by default in every installation. In summary: actually paying attention to possible attacks and ensuring you're defended against them, and reducing the surface area for attacks makes your application much safer. [1] https://docs.oracle.com/javase/10/core/serialization-filtering1.htm#JSCOR-GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A https://docs.oracle.com/javase/10/core/serialization-filteri...