3 ms·
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
by jrumbut 4y ago
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.
- quanticle 4y agoExactly. 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.
- jrumbut 4y agoAnd 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.