Comment by quanticle | Hacker News Reader

Comment by quanticle | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com