Corporate Cultural Issues Hold Back Secure Software Development (betanews.com) 57
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.
Likely worse than that (Score:3)
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.
Re: (Score:2)
Most 'DBAs' are overpaid backup monkeys.
The ones that aren't, are backend database _programmers_.
Re: (Score:2)
Yeah until you need a real one. After some programmer who thinks he is clever unleashes an abomination into production and walks away from it.
I've seen things you people wouldn't believe. ; no primary keys, no central tables, spreadsheet normalization, deadlocking, no primary keys, no foreign keys, Oracle databases crippled because no one read the manual explain the difference between; SYSTEM, SYS, and SYSOP; backup disarrays thrashing due to scratch writes to the DB, objects polluting the database sending
Re: (Score:2)
I'm saying I have seen it. Even in "reputable" companies.
Re: (Score:2)
If a dev doesn't know about primary keys and foreign keys in a relational database, fire them on the spot. Dev should always look into simple solution, and manually managing data integrity is far from being easy.
Devs tend to do whatever is easiest, most convenient, and fits their personal style. Not many get beyond that.
And yes, I've seen the same kind of thing. In one case the database became a de facto standard for the industry it was in too, getting written into the official documentation even by clients for others. I really wanted to rip it apart and fix it b/c it was so badly designed from a DB point of view.
Re: (Score:2)
and not just them but the frameworks that everyone uses to build their applications - using .NET core right now and the extra bits that I have to put in to make it secure is remarkable. Meaning, why aren't these features in the framework from the start, or at least as code is auto-generated, why doesn't it come with all the security restrictions you might put in, as if you don't need them its easier to delete the annotations and code than it is to put it in.
and if it wasn't for a lot of browsing stack overf
Re:Time-to-market is critical (Score:4, Insightful)
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.
Re: (Score:2)
The right answer is both security and time to market matter, ignore either and your pretty much guaranteed to fail.
That's not true. We could easily list many companies large and small who are incredibly successful who have had advisories issued for their products, or data breaches, or where we reasonably suspect their products wouldn't be too hard to break if we put the effort in.
However, failure to get to market first can kill you dead. Can't invest in product security for a product that is cancelled. Security issues will cause you some pain and maybe a fine. And if you do get fined, it's likely going to be related to
Re: (Score:2)
Unless you have no competitors, you can't get away with shipping windows ME in 2017. Even PackardBell eventually went broke.
Ask Kaspersky how 'just shipping' worked out for them.
It's mostly about development tool selection. But it's also developer culture. I do agree there is no SECURE. Certainly no simple secure.
There is also the cost ratio of bugs found in house vs bugs that make it into the wild and the high cost of retrofitting security.
It is about tradeoffs, time to market is very important. B
Re: (Score:2)
You can't ship ME in 2017 because there is no demand for it. It's been long superseded.
Kaspersky's problem isn't security, it's the accusation it is being intentionally used by foreign intelligence.
I agree it is about trade-offs, and that security is important. But it's always about evaluating what are the priorities for your business right now, projecting forward, and re-evaluating periodically. There's no blanket answer that applies to every case.
Re:Time-to-market is critical (Score:5, Insightful)
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.
Re: (Score:2)
an "easy" way to do both is to have a code library that is pre-vetted and known to be secure.
(why start from scratch every time you need to do a Login??) script your setup to red flag known issues and you won't get hit with the "Everybody Just Shoot Yourself" level security issues.
Re: (Score:3)
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.
Re: (Score:2)
What's getting us in trouble is not that "getting something out there" is prioritized over security, it's that "now that we're out there, get the next greebly out" is prioritized over security. There's a wide range between "if it's not perfectly secure it doesn't ship" and "security? Forget that, I want colored fonts."
That said, if you're the first in the field, nobody's going to know you spent an extra two months making it secure before initial release. If you're playing copycat, though, it takes something
Re: (Score:3)
Re: (Score:2)
An excellent example of cultural issues that hinder secure software. Also a good argument that it's not a company specific problem, but a problem with the design of the more general economic and cultural system.
This is *not* an argument saying that your point is invalid in the current context. It's an argument saying that the current context is a major part of the problem.
Security company funds "study", finds problems (Score:5, Insightful)
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".
Re: (Score:2)
Agreed, and furthermore, the article doesn't specifically state who they interviewed. I originally read that to mean it was an INTERNAL study.
Also, I find "cultural issues" to quite possibly be the best euphemism ever used to describe "greed."
Welcome to DevOps... (Score:2)
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).
Re:Welcome to DevOps... (Score:4, Funny)
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
And then one day management and the scrum master awoke on a bright cheery morning. Sun shining bright, birds chirping. What a glorious morning! They got their Starbucks coffee, kissed their wives and kids and drove into work with cheerful positive music and thinking very highly of themselves and how fortunate their company was to have them. For without them, the company wouldn't be able to function. The scrum master skips through the door, smile on their face and spring in their step and goes into the empty meeting room where the daily stand up is supposed to be. 5-10 minutes pass after the stand up was supposed to start and there was still no one there but the Scrum Master. Why could this be? Where is everyone? They must be late! Those lazy no good slackers! And then it dawned on the Scrum Master, I fired everybody because they didn't meet my ridiculous expectations and I can't write a line of code to save my life. Without anyone to scapegoat the problem onto, because they were all fired, the Scrum Master panicked, chaos ensued, angry customers called the CEO and eventually the business closed its doors and faded into history as another failed startup.
Re: (Score:2)
I think you must be referring to the product owner, not the scrum master... if the same person is both, you're doing it wrong.
Re: (Score:2)
unmod
Re:Welcome to DevOps... (Score:4, Interesting)
Hyperbole aside, this isn't new to 'DevOps', though I will admit that in some circles it blesses the thought process.
For as long as humans have been doing things, processes in bad groups devolve to this sort of blind and mad grasping at 'productivity', and devolving into spending more time fretting about the process of seeing if work is being done than actually doing the work. Each fad promising to 'correct' the ratio of overhead of the previous fad, either never realizing or intentionally ignoring the reality that people are the problem and will pervert any methodology that purports to fix it.
Meanwhile, good teams operating within good larger organizations will succeed with whatever project management/development fad they nominally use.
Re: (Score:3)
I have a feeling I've worked with you before.
Re: (Score:3)
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 c
Re: (Score:3)
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.
Several things holding back secure software (Score:5, Insightful)
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.
Re:Several things holding back secure software (Score:4, Insightful)
I think 3 is more insidious than you give it credit for. "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"?"
There is a perverse logic to, "It's never bitten us in the ass before, why should we start worrying now?" That's doubly so when success before was predicated on not giving a shit about security, and beating someone else to the market who did.
This works very, very well, up until the point it doesn't. The problem is that the data points build up supporting this flawed logic every time it's a successful gamble.
And then, what if it's not a gamble? Looking at Windows, it's spent 20+ years as a multi-billion dollar making piece of swiss cheese. From a manager's standpoint, it's hard to point at that sort of success and say, "We should have held back some versions another 6 months to a year and fixed some of the bugs."
It's not a corporate culture issue as much as it is a dollars and sense argument. If an early flawed release is going to make you more dollars than a later secure one, it makes sense to release your software early, holes and all. Over time, this may become corporate culture, but I'd argue that once it stopped making financial sense that most companies would revisit this habit.
Re: (Score:2)
Don't understand or Don't care? (Score:3)
"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.
Security not always helped... (Score:3)
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.
Bottom Line (Score:5, Insightful)
Corporate Bottom Line Hold Back Secure Software Development
FTFY
Please, let's cut to the chase. (Score:1)
Animal psychology issues hold back a lot more than that... culture is quite secondary. There is no mystery as to causation. The brain stem is still the master.
This is easy to solve. (Score:5, Insightful)
Just tie the pay of the managers to security. If there are security issues then the managers start losing money. Problem solved!
Re: (Score:1)
That already happens, but not in a vacuum.
The manager has to decide which is worse, added risk of a security lapse versus not delivering the product. And don't just say "any security lapse means the manager goes to jail" - you either deliver a product or you don't. It'll never be 100% perfect but if it isn't delivered it's a 100% failure.
Not fair, not surprising (Score:2)
Maybe locks themselves, hopefully safes and vaults, but virtually no other industry could afford to be as security focused as we're requiring of software here.
My car door is easily opened without the key. The wipers are easily removed. A jeep can be dismantled with an Allen key.
My front door has a deadbolt, with a big glass window next to it -- no bars.
My Telecom services are connected in a box on the front line. Right next to the water shutoff.
Virtually everything in our lives is completely insecure.
We enc
Because security gets in the way (Score:2)
No one wants security, and not just in code.
I mean, in order for people to use safety gear that can save their lives, we need strict regulations and punishments. And I don't mean employers not caring about employees safety, I mean employees having everything they need at their disposal and not using it despite the signs.
Security is about spending time doing non-functional stuff and restraining yourself. People hate that. And even if it is provably useful, it goes against human instinct which is to prioritiz
Indeed (Score:2)