Slashdot Mirror
Corporate Cultural Issues Hold Back Secure Software Development (betanews.com)
An anonymous reader shares a report: As the digital economy expands and software becomes more critical, security worries grow. In a new survey, 74 percent of respondents agree that security threats due to software and code issues are a growing concern. The study of over 1,200 IT leaders, conducted by analysts Freeform Dynamics for software company CA Technologies, finds 58 percent of respondents cite existing culture and lack of skills as hurdles to being able to embed security within processes. In addition, only 24 percent strongly agree that their organization's culture and practices support collaboration across development, operations and security. On top of cultural limitations, less than a quarter of respondents strongly agree that senior management understands the importance of not sacrificing security for time-to-market success.
I think it's likely worse than that. The problem is that the "respondents" aren't necessarily people good at spotting where there are problems or what the nature of the problems are.
In other news, Microsoft finds that adopting Windows will work best for your company, Monsanto funds a study to say their crops are the sure way to make money as a farmer, Ford funds a study that says they make the best cars and trucks, Coca-Cola funds a study that finds their products are the most liked, etc.
I don't disagree that security is a problem, I just have a fair bit of skepticism that a study funded by Computer Associates, takeover-and-neglect artists of the software world, is really going to get to the root issues that make integrating security into software development processes without a fair helping of "we can send an army of consultants to help you for a fee, in addition to licensing some software we acquired and will resell/license to you at a pretty large markup".
I have seen this myself. I had a DevOps job (which I leaped from, to a far better place) where the Scrum master (who had the power to recommend terminations, and managers rubberstamped them) where the dev team was always in a sprint. Every morning, there would be a 4-6 hour stand-up meeting where each dev would be interrogated about their code and where their build was. Each coder had to justify their existence, and why they fell short of the standing order of a huge amount of lines/day (around 10,000). This turned into hours of blamestorming and finger pointing because people had to find a something that was blocking them in order to save their jobs.
In that environment, people were far more interested in getting their code working than even thinking of security. The gamble they made was that if the company got sued due to bad security, it might filter to them eventually. However, not meeting the story or epic deliverables come stand-up time was a 100% guarantee that they would be pink-slipped.
Security issues can be patched later on. If you are beaten to market, in many cases you might as well send everyone home and close up shop. Launching ahead of the competition and establishing a beachhead is the single most important thing with any product and everything else is #2. I understand that many engineers don't understand this, but they are not paid or trained to think this way. That doesn't make it any less true.
The problem with ignoring the priority of security is often times the priority of safety is dismissed as well. When that happens, innocent people die.
And when Greed N. Corruption essentially never gets punished for immoral, unethical, or even illegal activity, don't expect the environment to get any more secure or safe.
1) Corporate Cultural issues aka employee engagement - seriously if upper management is toxic and plays psychological games, who is going to give a shit about your software on any level let alone security?
2) Lack of software engineers with appropriate level of skill, education and experience. But you know it's because we can't find qualified candidates aka ones that are unicorns that will take minimum wage as compensation.
3) Companies that don't take security and risk seriously because hey why do we need to take this seriously now? We didn't take it seriously 20-30 years ago and now you're asking me to spend more money than I used to on "best practice"? You're just trying to trick me into giving away my precious money on things we really don't need like all those RAD tools I've been pitched over the years...
I could go on ad nauseum here but the TL;DR is: if you treat your employees like expendable pieces of shit that can supposedly be replaced by interns and contractors and tell them they should be thankful for it, your software is going to be shit on every level not just security.
We'll make great pets
"On top of cultural limitations, less than a quarter of respondents strongly agree that senior management understands the importance of not sacrificing security for time-to-market success."
time to market can be a make or break for profit. So how much liability are you willing to accept to make a profit ,if the alternative is bankruptcy , I'd say most managers would 'go for broke' and accept whatever risk is necessary to make a profit.
That is much the same reason we have the FDA, because large food companies , when left unregulated , have in the past, killed more then a few people in the name of greater profit.
There sooner or later will be more regulation on security critical software then there is now. That will slow down innovation, but prevent loss of life and property. A trade off that must be struck somewhere and will, weather good for everyone or not , be solved based on public perception.
âoeTolerance applies only to persons, but never to truth. Intolerance applies only to truth, but never to persons.
less than a quarter of respondents strongly agree that senior management understands the importance of not sacrificing security for time-to-market success.
So the problem is that senior management may understand, and the answer is not one that security experts like. Financially speaking, it may make sense to be a little fast and loose with security, or at least faster and looser than hardline security guys want. Security problems represent a liability, and for some cases not much liability, some times it *could* ruin your company, depending on what sort of company you are, the data you have, and which part of the data could be hypothetically compromised by the subsystem at hand. These have to be weighed against the cost of prevention both in terms of staffing/consulting and opportunity cost when your paranoia causes you to not implement a scary feature that your competitor does, or to be a year later than a competitor.
Complicating things, there's a disconnect between paranoid security practices and where the largest breaches come from. The vast majority of breaches come from someone putting a crappy credential on something. This is overwhelmingly bad practice and overwhelmingly basic. The reaction to a breach in the industry is for security guys to use it to go to town, enforcing more and more draconian limitations using more and more inscrutable approaches to mitigate risk, even though the existing processes would have already defended them adequately if applied correctly. It's like never taking a shower because you keep reading about people drowning in the ocean. There's not the risk in your shower, but water-related death is a thing, so why take a chance.
Meanwhile, time to market and availability are both negatively impacted when security-focused guys rule. In their job description, there is *insane* risk associated with ever saying 'yes', and generally not much risk associated with saying 'no'. They also know damn well that for all their effort, they will *not* get the whole picture, whether the team being reviewed intends to or not, they will never catch all the poor security decisions, further driving them to be paranoid in hopes they mitigate everything the company does in the hopes of catching the mistake in general roadblocks.
The general corporate reality of 'external' security teams reviewing the efforts of 'non-security' teams leaves a lot of room for the worst of security policies inhibiting productivity and of insecure design getting through that the security team is going to be oblivious to. The answer is an embedded understanding of security principles in the day to day, but that truth is too inconvenient as that is quite an expensive proposition. They want to take unskilled folks and duct tape security on by having a small band of security 'experts' tick a checkbox in the process.
XML is like violence. If it doesn't solve the problem, use more.
Not always.
I've worked at shops that were supposed to be HIPAA compliant and, on paper, we were. In practice, however, we always took shortcuts - not for time to market issues either but for performance reasons (as in how fast the app runs) or logistical reasons (Yeah we know encyrption 2 has issues but our team can't go to encryption 3 until team b, c, d, and e have updated and they don't have the cycles) I have friends that work in the financial industry and they encounter the same problems.
In every company I've worked at though, as engineers, we've always enforced a level of security that we'd demand if this was in our own homes or our data.
In the times we didn't consider security it was for data or apps that were practically "valueless". Imagine our surprise when our early 2000s home network music servers got connected from outside sources and were used as remote data storage servers! They could read the music but couldn't delete the files because we had stored the files under the account ID which was password locked (and then only to prevent a user from accidentally deleting it) - but never bothered locking down the system as a whole coz it's on a home network!!!
Same goes with online game cheating today.
Ignoring your ego jerking...You assert that time to market doesn't matter?
The right answer is both security and time to market matter, ignore either and your pretty much guaranteed to fail. Which is a more difficult discussion than just saying 'you're the problem'.
And of course the rubber hits the road when security breaches happen. Management sees the lack of consequences and manages based on history. Putting a music major in charge of a major corps IT security should reduce the stocks value to zero. That is the bottom line.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Corporate Bottom Line Hold Back Secure Software Development
FTFY
Just tie the pay of the managers to security. If there are security issues then the managers start losing money. Problem solved!
Anons need not reply. Questions end with a question mark.
Yep, I've seen this before. Stuff like claiming redundancy out of two datacenters in geographically-separated areas of the country, yet we were actually operating hot out of both.
Fully licensed blockchain psychiatrist
Security issues can be patched later on. If you are beaten to market, in many cases you might as well send everyone home and close up shop. Launching ahead of the competition and establishing a beachhead is the single most important thing with any product and everything else is #2. I understand that many engineers don't understand this, but they are not paid or trained to think this way. That doesn't make it any less true.
It's this line of thinking that is getting us in trouble time and time again. Glad you popped in to show us exactly what's wrong.
Security has to be designed in to be good. Patched later on - how's that working out for Intel just now?
Why guess when you can know? Measure!