3 ms·
It seems that companies would rather buy "insurance" rather than spend money on actual security. They have accepted that they will eventually be hacked or have
by rashkov 9y ago
It seems that companies would rather buy "insurance" rather than spend money on actual security. They have accepted that they will eventually be hacked or have a really expensive outage, so now they want a cushion of money to pay for any penalties and lawsuits.
I get the impression that for the most part, no one really believes in security, and doesn't understand that it's a process and not a product. They already tried throwing money at the problem by purchasing security products, which ultimately failed to deliver security. Now they're trying the opposite by cutting costs. Meanwhile there are very few consequences to losing control of people's data.
- jdavis703 9y agoWhy aren't there Security Process Engineers (SPE)? I was recently waiting on a massively delayed flight and observed three instances where employees left the computer behind the check in desks unlocked. I'm sure these computers checked off all the requirements for having a firewall turned on, anti-malware software, auto-updates turned on, etc. But the front door was left wide open because the employees were forced to move between their counters and the actual jet bridge. Since they get penalized for late flights, but not for security breaches it seemed as if they didn't care. This would be where a SPE would come in and propose something to remediate the process failure.
- konceptz 9y agoThere are certainly this type of thing out there. SSI or software security initiatives, when given greenlights based on buy in from governance can introduce secure processes. But before this happens to any meaningful level, risk based anaysis should prove it is cost effective. Guess what those analysis say?
- yeukhon 9y ago"They already tried throwing money at the problem by purchasing security products, which ultimately failed to deliver security." So true. I used to wonder why corporates can't build a real security team. One would spend $1M on an annual contract but perhaps you will do okay for $700,000 for a few security engineers. Then I realized that most corps are indeed looking for insurances. You see, managed security vendors have a team. You don't manage the hiring, the tooling building etc. Obviously you can't just sit back and watch them put out the fire. You train them to understand a bit about your environments, you work with them on triages and resolutions, and you work with them to integrate your systems with them (e.g install an agent etc) But it isn't most enterprises' interest to build a strong security team. Many of the in-house security team's role is to manage incident response. Many of them don't really have a say, they are often consulted and that's it. Many of the product demos sound exicting and if you are not careful during your POC you will end up with a medicore product. Even if you did your best during POC yo evaluate the product, you will realized the product is really medicore. It caught the low-hanging fruits and are full of false positive. You ask for better analysis but because they come in as black-box, there is a lot of back and forth before you can act on the issue. So at work I would get a ticket from the vendor and I would end up doing a lot of the analysis. That sucks because while I enjoy doing security triage, that's not my role, but the conflicting side is at least they caught something. I would have to engineer or deployment some solutions and monitor the whole thing, since no one man or team can do everyone's job. Since no one wants to be responsible for other's job, that's the whole point of having a secuirty team. It just happens that team, the people who are building tools and monitoring incidents are outsourced. Most importantly, there is very little control of what your vendor can do. Want a new feature? Want better reporting? Want to change some configuration? A lot of time you are out of luck, or you need to be patience. But, seriously, security practice is not magical. There are best practices such as SSH to server using key or cert authentication, not password. Least privilege to run processes, so system admin/devops should create a checklist on what's in place what isn't. It does take a serious committment from management to move forward though. And security is an iterative process. Evaluate the best most secure option possible for the moment being, and put a realistic plan together for the remaining unresolved concerns.