Hacker News Reader

Comment by twunde | Hacker News Reader

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

View on HN

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?

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.

Reply on news.ycombinator.com