4 ms·

I think you could take this further. There's another "log4j" vulnerability out there right now, I guarantee it. It might be exploited, it might not be. But ther

I think you could take this further. There's another "log4j" vulnerability out there right now, I guarantee it. It might be exploited, it might not be. But there's no patch. What are you doing about it? With log4j you have a brutal combination of: 1. RCE 2. Exposure RCE happens frequently but often attackers don't have an easy time getting to the exploitable code. With log4j it's trivial - every app can be owned. But here are some questions: 1. Why do those apps have the ability to make network requests? 2. For the apps that need to make those requests internally, why aren't those over mTLS? 3. For the apps that need to make them externally, why isn't that going through egress proxying? 4. Why are there credentials spewed all over your environment variables across your services? Are they short lived? It's actually not super hard to have a worst-case scenario vulnerability like log4j be not that bad for your organization. A bit of hardening and even if something like this happens you're in a good position to wait, monitor, and patch.

querulous 5y ago
it's definitely time for a language with a capabilities based security model that allows scope to the function/method level, at minimum not just for security either. i can't count the number of times i've traced a performance problem or bug to a piece of code that was doing some io when it didn't need to
- staticassertion 5y ago
  Agreed. In a capabilities system you'd see that, for some reason, your logger requires all sorts of absurd capabilities for no reason.
- hyiltiz 5y ago
  Haskell comes to mind?
twunde 5y ago
Regarding your questions, they make sense in the context of modern software built in the last 5 years. However, most large enterprises have a long tail of legacy applications built years ago. These may be inherited from a combination of acquisitions, from vendors that have since gone under, some from. The common factor is that the original developers are long gone, and they may be supported using a skeleton crew or not at all. Documentation if it ever existed is likely lost. What these applications are supposed to connect to are likely unknown. This is a major problem at enterprises
- staticassertion 5y ago
  Yes, some organizations have so much technical debt that any security work is going to take extraordinarily large amounts of work. That's a bummer, but I suspect many on HN can in fact build software that isn't total garbage.
  - aidenn0 5y ago
    Doing it right sometimes pays off in the long run, but cutting corners always pays off now.
    - ChuckNorris89 5y ago
      Exactly. Managers and execs love pointing out the cost savings they made this year or this quarter. By the time the chicks start to hatch "in the long run", they most likely would have already moved to another enterprise so someone else has to clean up their mess. And by clean up, I mean repeat exactly the same mistakes since nobody promotes you for implementing stuff that might show its benefits in the long run.
      - paledot 5y ago
        Also one of the root problems with politics. 2035 emissions targets are the next government's problem. Rehabilitative policing pays off in 20 years, retributive buys voters now.
- to11mtm 5y ago
  Egress is a very fair question IMO. I've worked at more than one place where Infosec would start integration talks at 'What are the static IPs and how do we rotate certs' Every layer you go lower (longer certs, domain whitelisting vs static IPs, etc.) is a tradeoff of maintenance and security. > What these applications are supposed to connect to are likely unknown. This is a major problem at enterprises Only if they fail to consolidate vendor integrations and/or have already insufficient staff. (Which is often indeed a problem.) Simple, if brutal solution; Infosec audits logs and works with application teams to confirm existing traffic and pre-document new traffic out. With properly staffed teams you should run out of surprises within a year.

querulous 5y ago

it's definitely time for a language with a capabilities based security model that allows scope to the function/method level, at minimum not just for security either. i can't count the number of times i've traced a performance problem or bug to a piece of code that was doing some io when it didn't need to

staticassertion 5y ago
Agreed. In a capabilities system you'd see that, for some reason, your logger requires all sorts of absurd capabilities for no reason.
hyiltiz 5y ago
Haskell comes to mind?

twunde 5y ago

Regarding your questions, they make sense in the context of modern software built in the last 5 years. However, most large enterprises have a long tail of legacy applications built years ago. These may be inherited from a combination of acquisitions, from vendors that have since gone under, some from. The common factor is that the original developers are long gone, and they may be supported using a skeleton crew or not at all. Documentation if it ever existed is likely lost. What these applications are supposed to connect to are likely unknown. This is a major problem at enterprises

staticassertion 5y ago
Yes, some organizations have so much technical debt that any security work is going to take extraordinarily large amounts of work. That's a bummer, but I suspect many on HN can in fact build software that isn't total garbage.
- aidenn0 5y ago
  Doing it right sometimes pays off in the long run, but cutting corners always pays off now.
  - ChuckNorris89 5y ago
    Exactly. Managers and execs love pointing out the cost savings they made this year or this quarter. By the time the chicks start to hatch "in the long run", they most likely would have already moved to another enterprise so someone else has to clean up their mess. And by clean up, I mean repeat exactly the same mistakes since nobody promotes you for implementing stuff that might show its benefits in the long run.
    - paledot 5y ago
      Also one of the root problems with politics. 2035 emissions targets are the next government's problem. Rehabilitative policing pays off in 20 years, retributive buys voters now.
to11mtm 5y ago
Egress is a very fair question IMO. I've worked at more than one place where Infosec would start integration talks at 'What are the static IPs and how do we rotate certs' Every layer you go lower (longer certs, domain whitelisting vs static IPs, etc.) is a tradeoff of maintenance and security. > What these applications are supposed to connect to are likely unknown. This is a major problem at enterprises Only if they fail to consolidate vendor integrations and/or have already insufficient staff. (Which is often indeed a problem.) Simple, if brutal solution; Infosec audits logs and works with application teams to confirm existing traffic and pre-document new traffic out. With properly staffed teams you should run out of surprises within a year.