Comment by staticassertion | Hacker News Reader

Comment by staticassertion | Hacker News Reader

Parent Full thread

staticassertion

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.

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

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.

Doing it right sometimes pays off in the long run, but cutting corners always pays off now.

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.

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.

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.

I suspect that a manager that suggested / insisted on such properly staffed teams, would get fired or no longer promoted, at most big companies. Since it'd cost a lot, and not show any results the nearest time / years. And also, they might hire the wrong people, and just burn money for nothing

> Simple, if brutal solution ... properly staffed teams

The recruitment part is not simple, maybe bordering to impossible? for some larger companies. I say, based on my past experiences in how clueless big companies can be concerning what technical people they hire.

> and not show any results the nearest time / years.

Depends on how you game OKRs. Implement auditing Q1. Contact all teams Q2. Have 75% of teams Q3. 90% of teams Q4. Just an example but its all in how you sell it. Big IT understands icebergs, you just have to give a good/accurate roadmap and execute if they agree on it.

You might be correct that a lack of insight on this sort of thing is an organizational problem. My experience indicates that if you can't get a list of dependencies based on a series of e-mails down an org chart, something is wrong. Either someone is managing too many services for the level of tooling you have, or there's a complete breakdown in org comms (which happens more in larger enterprises.)

Sounds interesting, but what does "Have 75% of teams Q3" mean?

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

Agreed. In a capabilities system you'd see that, for some reason, your logger requires all sorts of absurd capabilities for no reason.

Haskell comes to mind?

Reply on news.ycombinator.com