Hacker News Reader

Comment by agentultra | Hacker News Reader

I'm sure they had lots of reasons.

I got to ghost on a sales call once with one of our customers (I was a lead developer at the time).

From what I could tell their IT people didn't like our software because:

- They were already in the middle of a multi-year roll-out of SAP, integrating our software was a wrinkle in a plan they'd been working on for a long time

- Nobody got fired for choosing SAP, some saw choosing software from a small shop they'd never heard of was risky

- Annoyance: they were in charge of acquiring and rolling out the software the factories used! Why were the floor managers demanding that they integrate our software? What do they know about software, enterprise contract negotiation, etc!? How dare they!

- Support: they knew how to handle issues with SAP, user accounts, authentication, authorization, etc; integrating another piece in the mix across the entire company would be a whole project

It was a fun call to sit in on.

View on HN

Another reason that people often overlook is security. Even if each individual software product has a good security model, differences in the way they interact can lead to security vulnerabilities and opportunities for attackers to move laterally through a network. In the case above, it may be that IT knows how to integrate SAP with their Active Directory system in a manner that ensures that users have access to the data that they need, without giving everyone write access to everything. A brand new product from some small startup, even if it's competently engineered, won't have the same pre-set integration playbooks as SAP. The in-house IT will have to figure it out themselves, which adds time and overhead for every operation. New hire? Before, you'd give them a SAP account, and you'd have a playbook that would automatically or semi-automatically provision everything for them. Now, you have to provision accounts in two systems. Compliance? IT already knows how to validate an SAP install for compliance and generate a report for the appropriate regulators. Now they're going to have to learn to do that with your new system. And so on.

I listen to several infosec podcasts, and one recurring theme in those podcasts is managing users who do "shadow IT", i.e. by buying and integrating new products or software that make their day-to-day jobs easier, but do so in a manner that opens up huge gaping security holes that IT doesn't even know about… until the breach happens and the company is all over the news for leaking customer data.

Security is important. What makes SAP secure? I personally found errors in customer systems. And at the time even Microsoft couldn’t implement OAuth2 correctly with regards to the specifications… which is no surprise given how often it had to be amended.

A good deal of “security,” even in the enterprise, is a lot of theatre and show boating. Write a formal specification and throw it at a model checker and you’ll probably start finding holes in most software stacks. But hardly any software developers do that let alone IT managers.

The later generation of the stuff I was working on at that company had to also be certified under certain important regulations. The system had to be able to be auditable in the sense that application logs couldn’t be repudiated in court and users couldn’t tamper with data. That was some pretty serious work.

But yeah.. there’s a lot of “lol security” out there and as an IT person trying to manage ISV solutions it can be a huge pain trying to sort the wheat from the chaff.

But just buying MS or SAP and thinking you’re done with security is also as bad. Don’t overlook security.

    What makes SAP secure?

Nothing, inherently. What makes SAP secure is that a lot of IT organizations have experience with setting it up, and know enough about its pitfalls to avoid them. With a new product, IT is going to have figure out the security pitfalls (hopefully by reading documentation, but more likely through testing, hopefully not through breaches). If, as the grandparent post indicates, the product was set up by someone outside of IT, it's quite likely that that person doesn't actually know about security, and may well have inadvertently opened a security hole by, for example, creating an insecure proxy account.

To re-emphasize my point from my original post: far more security problems result from the interaction of systems than result from systems themselves. SAP may be set up in a perfectly secure manner. The new product may be set up in a secure manner. However, their interaction may still result in data leakage or denial of service.

Even if your product is perfectly secure (which it isn't), the mere fact that it's one more component, interacting with all the other components of the company's IT infrastructure, is reason enough for broader corporate IT to be cautious.

Furthermore, it's often the case that when there is a problem, security or otherwise, it's not going to be your customer that's on the hook. It's going to be the company's IT department. Would you like to suddenly support a piece of software that, a week prior, you didn't even know existed, much less deployed at your company?

To your point: I remember going to our IT security people asking for them to allow us to add Python to our computers. We said, "there's nothing in Python that Excel can't do" (not 100% true). Their response was, "If we could prohibit everyone from using Excel, that would be our preference too."

Given how many times they must've been burned by end users opening infected Microsoft Office documents, can you really blame them?

This was a lesson I learned very recently.

As a dev, I think about security in terms of exploits and making sure software doesn't have them (as well as having features required to implement user/data policies).

An IT person thinks about policies too but for them security is primarily about tools. If a piece of software will work behind their firewall and IDS, integrate with their monitoring software and Active Directory, export reports in the format this or that other tool needs, then it's secure from their perspective.

It makes sense when you think about it, and actually allows for a fair bit of freedom once you understand the boundaries. What is unfortunate is all the time I wasted gathering pen-test reports and all kinds of other junk when that wasn't the real problem at all.

Exactly. A lot of developers focus on lack-of-vulnerabilities as the essential aspect of security, when, in reality, for corporate IT, the essential aspect is visibility. It doesn't matter how secure a black-box app purports to be, the mere fact that it's a black box that IT has no visibility into it will (justifiably, IMO) lead IT to treat it as insecure.

And that's all fine, but when the IT Department turns itself into a black box and doesn't tell anyone what bar software needs to clear to be used that's when shadow IT happens.

> Annoyance: they were in charge of acquiring and rolling out the software the factories used! Why were the floor managers demanding that they integrate our software? What do they know about software, enterprise contract negotiation, etc!? How dare they!

Ok, so this one I actually kind of agree with. Too many times I was in a position where a bunch of decisions were made about software or hardware, and then IT was brought in at the last minute to try and get it all to work in an unreasonable time frame. And then IT was asked it integrate it in impossible ways.

If another department brings IT in early, different story. I got in to IT to use technology to make people's lives easier, not to play with whatever the latest fad bullshit is or develop an inflated sense of self-worth. If some random nobody's software is going to do that at the cost of a minor annoyance to me, that's fine.

Having worked both sides of this, it's generally the case that IT is absolutely terrible at their job that ends up with them getting called in late.

Company: "IT is terrible at their jobs, what are we going to do about this!"

IT director: "Give me a budget to hire competent IT people"

Company: "On the other hand, we're ok with this IT incompetence"

Interesting, in my experience generally it's business types that don't know shit from their elbow and don't include IT early enough due to negligence.

My experience is admittedly limited but every case I've seen of IT being called in late was that IT would have reasons for no. The VP didn't even learn their lesson when circumventing IT ended up with all corporate e-mail down for nearly a week. (As predicted, although it ended up taking longer to fix because I was on the other side of the world, internet access but unreachable by phone.)

That's fair, 90% of people are shit at their jobs. I'm just saying, if it is me, I'm definitely upset you did that and I think I'm justified in that.

A low-trust environment is exhausting for everyone, and a difficult pit to climb out of.

I would guess that completely incompetent IT departments that only degrades everybody's work are very highly correlated to workplaces that use those huge, all in 1, hired consultants based software packages.

Sounds like a good reason to bring them in even earlier

Reply on news.ycombinator.com