Vendors Say Data Protection Software Too Complicated To Use
jfruhlinger writes "With a series of major data breaches over the past few months, you'd think more and more companies would be investing in data protection software, which can help keep data secure even on systems that have been compromised. Unfortunately, even organizations that have paid good money for this software often don't use it, because, as one of the vendors admits, it's often too complicated to use."
In other words, alot of enterprise software is poorly designed.
Well designed software is easy to use.
They should hire me to help them fix it.
Am I the only one who read this as: It's too complicated for the entry level IT guys we hire to use....
These things come and go in the security market faster than you can believe. The problem isn't the lack of need, it's that the security software market is a "me too" market filled with companies cranking out software that has the latest buzzwords. In the security industry, everyone just copies everyone's fad else instead of innovating and trying to find a more elegant solution to the underlying problem.
But it doesn't matter anyway, since these companies all target the suits instead of the IT folks. The suits will just buy whatever product sounds nice without consulting the people who will use or administer it. There's effectively no interaction between the vendors and their user-base. /rant
There's no -1 for "I don't get it."
The quality of IT people I have worked with over the last 12 years has slowly degraded over time. We are at the point now where "sysadmins" have the skills that a helpdesk person had 10 years ago. I think there is just so much demand that you have to pay more than companies are willing to spend to get a quality sysadmin or network admin type of IT guy.
Well designed software is easy to use.
Did you RTFA? This isn't Donkey Kong Jr. we're talking about here. DLP software, while extremely sophisticated, isn't that hard to use - What's difficult is the requirement for a company to create business policies that define what data is critical and what isn't. If you turn the alerts up too high, end-users and IT security are bombarded by noise and warnings, making the system useless. If you turn the alerts down too low, then you run the risk of data leakage.
I can't just say SOX compliance is too complicated and not adhere to it. Isn't there a consumer privacy or protection law being violated?
Hello, I see that you are trying to encrypt and backup your customer data....
No, what it means is that a lot of responsibility that IT managers (and higher) are given, such as ensuring that confidential data is kept confidential, is either too hard for them, takes too much time or they are simply incompetent to fulful that role. I don't mean technically - it isn't just an IT managers role to tick the right boxes in a menu, I mean if THEIR managers are unwilling to spend the time, money and effort on their own, then it falls to the person to convince them of the need to do so.
Moved to http://soylentnews.org/. You are invited to join us too!
And enterprise users are dumb. It's a bad combination.
lol... i remember when a friend called me telling me avira-or-whats-its-called for windows was taking 11hours already to check his 500GB harddrive...
the next day he called me telling me avira-or-whats-its-called for windows had just finished checking his 500GB harddrive... it found nothing but his system was still broken...
i told him to give up repairing windows and just reinstall it... hours later he called me again and asked me if i would download avira-or-whats-its-called for windows for him so he can reinstall it..
i'd just hang up because such people make me sad for some reason... and i turned to my linux system and did some serious work... you know... that lame operating system luckily nobody cares about...
the end
"can take two years to fully implement, he said."
"It's a mature market - please turn it on." John Vecchi
Well if it's mature already, maybe it just sucks?
Two years to implement a system that is 100% overhead, no services rendered! Fuck, that, shit. You're doing it wrong.
When will it catch on with software publishers & independent developers, that no matter how narrow your niche, there are very few excuses for utterly ignoring ease of use.
Free? : No.
Expensive? : No.
Really Expensive! : What are you smoking?
It's just hard work? : DUH, that's why you set out to make a tool for it right, it doesn't have to be a GD requirement.
blah! so then what is the need and we did because it must.
a lot of people think "alot" is a word.
There's no -1 for "I don't get it."
I've said this before, ease of use and security do not go hand in hand. In short they are generally not compatible.
The hard part is finding the right balance between them.
Ever wonder why crackers only get consumer data and not highly embarrassing confidential data strategic to companies. Like to see the what the top brass really gets payed including entertainment, where does that corporate jet really go, and what is the companies 5 year plan. Notice how its only your data - your credit card information - that is cracked but not the CEO's bank account information or their personal information. Guess companies can figure it out when it really matters.
Vendors Say Data Protection Software Too Complicated To Use
I have no problem at all using my data protection software of choice:)
You can't just pile software on top of a broken system/design and magically have everything secure.
What surprises me in all this is that the banks are *not* jumping all over these companies for exposing consumer credit card information - whatever happened to PCI Compliance?
Did you RTFA? This isn't Donkey Kong Jr. we're talking about here. DLP software, while extremely sophisticated, isn't that hard to use - What's difficult is the requirement for a company to create business policies that define what data is critical and what isn't. If you turn the alerts up too high, end-users and IT security are bombarded by noise and warnings, making the system useless. If you turn the alerts down too low, then you run the risk of data leakage.
WOW, that's funny how it suddenly becomes a business problem when this software shows up! A sane person would reason, if the software invented this problem, the software should fix it!
Christ, we're supposed to be SOLVING problems with computers!
This reminds me of enterprise backup implementations and shaking down non-IT organizations for data retention policies. Like it's their job to analyze the risks of [not] having snapshots of their data from arbitrary points in time other than YESTERDAY.
These both clearly map to the real world and are not entirely an invention of IT folks right??
fucking idiots. And the worst part is they reproduce.
The problem is that you have IT managers that are trained to manage not understand IT, IT admins that are trained in only MS software, and users who aren't trained at all on how to use software effectively.
I've seen this happen a lot in business, the bigger they are, the less emphasis there is on positive IT policies or employing IT professionals who actually know what they are doing. The main emphasis in big business is to climb the corporate ladder, buy stuff from vendors you get kickbacks from, and employ people who are cheap or friends of managers.
The IT side of business is not getting any better, we're seeing data breeches, hacked sites, and takedowns happening on some of the largest corporations in the world. These kind of things would not have happened if IT managers, admins, and users were trained properly or employed for the right reasons.
In other words, alot of enterprise software is poorly designed.
Well designed software is easy to use.
I would't call ERP software (like SAP or Oracle financials) poorly designed, however setting up an installation up also takes years.
Looking into the specific differences between an ERP and DLP system may offer some explanation how come configuring an ERP is budgeted/paid for by the company while a DLP isn't.
1. Without an ERP, the guys that have the final say in approving a budget cannot work (CFO is blind): the impact is immediate and obvious. Without DLP, not so.
2. Even more, a ill-configured DLP (or even a well-configured one) is restrictive for all the users - sociopathic managers included - do I need to say more?.
3. Moreover, even if both of the system are in the "support for the process" category (not inherently on the direct line that gets income to the company), the ERP is "operational cost" (need it every day) while a DLP is a "risk prevention cost" (money someone will pay for "just in case").
Risk management is more specialized, more complicated and requiring more imagination than financial management: the difference between "how and what can go wrong in various and possibly obscure points of my business? Who would benefit of something going wrong for me; who's the possible attacker?" and "How much was spend and what revenue you think you'll get in the next FQ or FY from this-and-that well-known market segments"?
One on top of the other, the CEO/CFO and the minions will need to leave their mental-warm-and-comfy-place to understand the need for a well-configured DLP and approve/pay-for a 1-2 years contract with a specialized team of contractors to set the security systems (DLP included) in place. Its akin requesting an accountant to show imagination - an almost oxymoronic concept.
That until something extremely bad happens (think Sony)...
Questions raise, answers kill. Raise questions to stay alive.
DLP is the "most disappointing" portion of the security market primarily because of the amount of time it takes companies to identify the data they want to protect, create profiles and taxonomies to categorize it and put in place the software that will protect it, John Vecchi, head of global product marketing for security vendor Check Point told a Register reporter at the company's annual conference today. Impressively sophisticated applications that can differentiate top-secret plans for next year's product from ho-hum plans for one from five years ago – and apply security policies that don't allow secrets to be copied or carried out of a secure networks, for example – can take two years to fully implement, he said.
Sorry but DLP didn't have to be universally deployed throughout Sony for it to be effective in protecting a couple of customer databases and their various associated processes and dataflows. I've done it more times I can count, it's not that difficult for a company with the resources Sony has. Given the fact Sony doesn't even have a process for ensuring updates are applied properly across various inter-dependant components I doubt they even investigated using DLP let alone decided it was just "too complicated".
The article is about a quote from a marketing mouth from a single vendor, Check Point, who made a sound bite about how hard DLP is to use. And, just by coincidence, they're announcing a security product that is easy to use!
It takes thirty hours of training to use the product, and our IT guys are simply too busy putting out fires to get the training.
Don't try to say that knowing how to encrypt data with specialty tools should be a pay-raise. We've all sent encrypted messages in childhood to bypass detection by others, so what is the difference? Encryption is practically all over elementary fiction novels, so why not in the workplace?
Video Related... http://www.youtube.com/watch?v=GlKL_EpnSp8
It's weird that this article shows up - I've got the "Ads Disabled" option checked...
Did you RTFA?
This is slashdot, right?
It's not that enterprise users are dumb, it's that they care about their actual job, not some crappy software (OK, some of them are also dumb).
Socialism: a lie told by totalitarians and believed by fools.
I would't call ERP software (like SAP or Oracle financials) poorly designed, however setting up an installation up also takes years.
So, they're well designed as a jobs program for consultants, but they're pretty damn craptastic at being ERP software.
Socialism: a lie told by totalitarians and believed by fools.
The main emphasis in big business is to climb the corporate ladder, buy stuff from vendors you get kickbacks from,
So which vendors are these? I'm apparently doing it wrong....
... my job is hard, i don't want to do it. but pay me any way. cheers.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Over the past 23 years I have also seen how large corporations manage their IT departments and I have seen quite a few competent IT managers that have actual development experience in their backgrounds. I have also not seen any evidence of kickbacks from vendors being SOP as you stated. Contrary to popular belief there are some corporations that do support and manage their IT departments policy, intelligent hiring practices, and well thought out procedures. Trying to reconcile the IT data handling requirements with the business data requirements can be difficult. Just like the parent in this thread said it can be a fine line between securing data while also providing access.
Saying software is "Too complicated" is usually a cop-out by the users and the managers that are involved in purchase and/or use of that software. Most backup software while sophisticated is fairly user friendly however many managers don't really know (or care?) what is really required to set-up a backup and recovery solution.
On of the problems with setting up a reliable IT disaster recovery solution (I will stick to backup and recovery here) is for management to decide on the requirements. The most common solutions are basic spot and full recovery which could include multi petabytes of data and what could called base metal recovery in that only the basic OS is recovered after a system disk failure. Yes many companies still don't mirror their system disks although system disk or even data disk mirroring does not prevent deliberate or accidental corruption. Both of these backup and recovery techniques may require different software and this needs to be taken into account.
Another aspect of backup and recovery is on-site, near-site and off-site storage of backup media with costs varying from a few hundred dollars to millions of dollars.
Even after careful backup and recovery design you still need to test the recovery otherwise the company may be extremely embarrassed when a failure occurs. I have actually seen backup software that was configured to back up all the database infrastructure but failed to actually backup the database so that when the hard disk containing the data failed the company lost all its database which proved to be very costly. The person concerned with implementing the backup never tested a recovery which would have immediately shown that he had failed to include the database data in his backup software. I am quite sure many people here can come up with more horror stories of this nature.
There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
We just finished royally screwing up a database project. The database is mostly worthless because it assumes a set of non-existent processes. The business unit demanding the new database wanted better processes in place. But wouldn't define them. So the programmers had to put something in, and programmers who don't know what our business is have now defined our business processes (and poorly, of course) because the people demanding the magical database be built that fixes all their problems couldn't even be arsed to define what their problems were.
It's like having recipe software which you put recipes in, along with cooking instructions, and a robot makes the item. Then, once you have all the ingredients in, you realize you didn't have any cooking instructions. So you complain that the software doesn't have default cooking instructions programmed in that would just magically make cookies or cupcakes without you having to do all that extra work.
The problem isn't the software. It couldn't be any more user friendly. Just tell it what you want, and poof, it will pop right out. The problem is that the users can't be bothered figuring out what they want, so the software is at fault.
Learn to love Alaska
And enterprise users are dumb. It's a bad combination.
No, many users only do what they are told and in the majority of cases the blame rests firmly with the managers. In the enterprise managers like to "de-skill" users (Management 101) by placing them into restricted rolls. Some Managers hate professional people since these people are usually multi-skilled and leave if they are forced down a narrow skill path. The consequence of de-skilling is you end up with people who are poorly trained, but of course Management covers itself by stating that the users are not skilled enough and more training is needed so after that training those people who are a little smarter leave for better pay and conditions and so the circle repeats itself.
There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
Trying to reconcile the IT data handling requirements with the business data requirements can be difficult. Just like the parent in this thread said it can be a fine line between securing data while also providing access.
There should be little, if any, push back from IT to well defined business requirements. What I find is the "fine line" where IT recognizes bad business requirements and those in charge of defining business requirements don't (such as giving every administrative assistant in the company full permissions to every file because their bosses can't be bothered to actually do their jobs and the admin assistants back each other up so when one is out sick, any of the others in the entire company may be taking their place that day).
Yes, I've seen more than one database where the administrator of the database in IT had lower permissions than almost everyone who used it (though they could instantly elevate them, if necessary), despite working with it in a much greater capacity, and often then fixing screwups that would have been fixed if permissions were set according to reasonable business requirements.
But a business where the managers wanting a secure but usable database and are willing to define both of those terms almost always get what they want without any interference from IT, and no balancing act/reconciliation is necessary. It's only when they demand a "secure" database, but every manager and secretary in the company must have full access to the database (even what they'd never need or use) because they are management or support management, where I see there being a problem between IT and others. And it's not IT's fault, other than not being able to explain their points clearly enough to the people involved so that they understand what the issues are.
Learn to love Alaska
I would't call ERP software (like SAP or Oracle financials) poorly designed, however setting up an installation up also takes years.
The software you mentioned only includes backup methods to backup software. By themselves any backups are crude.
:) With SAP we have a 2, 5, 7 proportion that being "2" for the hardware, "5" for the software and "7" for the consulting and we will tell you when you can close your cheque book ;)
Setting up a backup solution for SAP or Oracle Financials should at the most take a few days although that is assuming your backup hardware and software is inplace. Even a recovery should if you have the appropriate backup hardware take a few hours in a worst case scenario. I won't de-nigh that the set-up of an enterprise database with appropriate computers, storage, backup hardware and software can take a while (a few months) but a few years? I would love to be on that type of project I could do with an extra mansion
One big problem I have found in the enterprise is security. With Oracle the DBA's don't like security software (example: SElinux) turned on since they need to arrange for ports to be opened and in the majority of cases this falls into the "too hard" category.
Actually with regard to Sony does anyone know what OS they were using with their database and what that database was? For crackers to get database information this would not really reflect on the OS since the blame in the majority of cases would fall on the DBA's.
There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
then it falls to the person to convince them of the need to do so.
It falls to the manager to hire someone competent and then listen to what they have to say. If a manager wants to know why and what data security he needs he should take a class. If he wants to be a manager he should manager. Responsibility should flow up the chain of command not down.
I would't call ERP software (like SAP or Oracle financials) poorly designed, however setting up an installation up also takes years.
... can take a while (a few months) but a few years? I would love to be on that type of project I could do with an extra mansion :) With SAP we have a 2, 5, 7 proportion that being "2" for the hardware, "5" for the software and "7" for the consulting and we will tell you when you can close your cheque book
As TFA says: installing and configuring a DLP is not very hard in itself, but
DLP is the "most disappointing" portion of the security market primarily because of the amount of time it takes companies to identify the data they want to protect, create profiles and taxonomies to categorize it .
I imagine that is where most of the time (and consulting paychecks) go into.
Questions raise, answers kill. Raise questions to stay alive.
I don't mean technically - it isn't just an IT managers role to tick the right boxes in a menu, I mean if THEIR managers are unwilling to spend the time, money and effort on their own, then it falls to the person to convince them of the need to do so.
You know, there used to be these things called ethics (mostly honesty, trust and integrity) that all the good workers brought to the office every day. But that was way back in a time when companies actually invested in their staff, looked after them for the better part of their career and in return expected them to protect the company's interests.
This good conduct was policed with a degree of strictness and care by managers, who were held responsible for the materials under their control.
Now, however, we have Data Protection Software. Oh Brave New World, that has such applications in it!
Crumb's Corollary: Never bring a knife to a bun fight.
I have also seen things like admin accounts being used by a group of people. Especially developers. The worst is when the developer hard codes the DB sign in information in the app config file they are working on and sometimes forgetting to remove the hard coded account when the app leaves the development department.
There is no such thing as software that prevents data theft. Once you accept that, you can finally get down to doing real security.
Until site operators decide to properly secure the back-end data on their sites, no amount of front-end security will stop the insecurity designed into their sites.
"If you don't give me a spec, whatever I give you meets spec."
say it, mean it and give em a lot of shit when they balk at the end result. Next time, they find time for the non coding parts of the SDLC.
Don't blame IT staff for this one, blame reality. Big surprise, they are unable to configure the magic beans to intelligently and proactively read and understand all outbound data and decide if it should or should not go out based on best practices and corporate policy! All without accidentally telling the CEO no even if he's sending porn to his golf buddies.
Since AI doesn't work that well on this type of problem yet, especially in real-time, we just expect them to work out every scenario in advance so it can quickly look it up in a table. I'm sure that can't be hard, but we'll be generous and allocate 12 man hours for that.
But just in case it turns out to be too easy, we'll store our most sensitive data on other people's servers.
Of course it's too complicated to use. That's because it doesn't (and can't for years to come) have the necessary AI capability in the first place.
Meanwhile, we apparently can't get people to apply their own natural intelligence to the same problem in the form of not sending that stuff out of the LAN in the first place.
Read "What To Do if Compromised", the official instructions for merchants who accept VISA cards. Sony is clearly doing some of the things VISA requires: "Do not access or alter compromised systems, i.e. don't log on at all to the compromised systems. ... Do not turn systems off. Isolate compromised systems from the network ..." Then they have to call the VISA Incident Response Manager, and the full list of compromised cards has to go to VISA, which parcels it out to the issuing banks for card cancellations and reissues.
VISA has the contractual right to send in a forensics team. VISA will assess fines up to $500,000 if VISA's security requirements haven't been met. If compromised data includes PIN numbers for debit cards, or CVV2 data for credit cards, which merchants aren't supposed to store at all, VISA sends in a Qualified Security Assessor. They check that the systems are no longer storing that data, and that all historical data of that type has been erased, before they go back on line.
Now it's clear why Sony is off line. Their actions look like what happens when a major debit card breach occurs and VISA sends in the forensics and security teams.
So there's your answer when management doesn't want to have proper security on credit card data. VISA can and will shut temporarily down your ability to accept payments. You'll have law enforcement, forensic auditors, and security experts questioning your management. Your company may have to pay sizable fines to VISA. Your CEO may have to explain the screwup to reporters.
And that's the good case. The bad case is when VISA decides you don't get to accept credit or debit cards any more, permanently. This happens routinely to screwed-up small businesses.
Enterprisey software is specially bad, but the Unix principles of KISS and "do one thing and do it well" have long been forgotten by the software industry (or corrupted into "lets treat the lusers as if they are completely retarded, and lets hide all complexity under the carpet, where it can ferment until it explodes in a mass of bloated detritus and bugs").
"When in doubt, use brute force." Ken Thompson
while a DLP is a "risk prevention cost" (money someone will pay for "just in case").
Risk management is more specialized, more complicated and requiring more imagination than financial management: the difference between "how and what can go wrong in various and possibly obscure points of my business? Who would benefit of something going wrong for me; who's the possible attacker?" and "How much was spend and what revenue you think you'll get in the next FQ or FY from this-and-that well-known market segments"?
I think that in general the banking crisis has shown us that even companies that should be experts at risk assessment often mess it up. I think that's where the general problem lies:
Managing and calculating risks is a hard thing. People tend to downplay or ignore risks, especially less obvious ones, even in nuclear plants or New Orleans.
One of the reasons of course is, that it's planning for the unknown. Often you don't have all the information and know all the threats.
RogerWilco the Adventurous Janitor
Let me see if I get this right. You can save it as a template.
1 - problems occur with Data Loss
2 - every vendor jumps on it with a "solution" product
3 - execs buy such product to make it appear they have done something
4 - nobody bothers to look at the actual problem, processes and possible alternative approaches
5 - the software doesn't deliver, a discovery made after spending a fortune on consulting to fit an essentially square peg in a hole that was actually round to start with (but nobody bothered to check that upfront).
6 - because the "solution" isn't, return to 1
Did I miss anything?
Insert
My company spent over $1M and more than a year later the system doesn't work, but management is too embarrassed or too clueless to pull the plug and demand compensation.
Good news to tell you: Yes , Trust your eyes! it's really!!! , 100% original , come withinternational warranty! free shipping ,P A Y P A L accepted! Fast and door to door delivery!
Macbook pro laptops i7 $280- 520 U S D
Apple iPhone 4G 32GB $260 USD
Ipad 2 64gb + wifi + 3G $330 USD
New Ipod touch 64gb$120 USD
Dell Alienware M17x laptops: $700
Dell Alienware M15x $500
MacBook Pro MC024 LL/A $510
MacBook Pro MC373 LL/A $485
BlackBerry Pearl 3G 9105$350
Nikon F 6 - SLR camera - 35mm$685
Nikon D3000 (with 18mm-55mm and 55mm-200mm lens)$315
Nikon D3X SLR Cameras$985
Canon EOS 5D Mark$565
Playstation 3 PS3 Metal Gear Solid 4$220
Free shipping , P A Y P A L accepted! Fast and door to door delivery!
The problem I often face is similar. Except that I like digging in to such software, making it work. The problem is that companies want dumbed down programs, so that my job is easier to fill should I up and leave. I completely understand their position. But it is very limiting, especially considering I work in mixed win/osx/nix environment, so the job won't be filled by some guy off the street anyways.
I8-D
But, it starts with policy and process. Our organization had a breach and they jumped right to the technology before making sure they had the policy right and getting technology to enable that policy. So, instead of having a tiered risk model for information, they carpet-bombed the enterprise and locked everything down. Productivity has probably taken a 40% hit.
3b - Profit??
...the bigger they are, the less emphasis there is on positive IT policies or employing IT professionals who actually know what they are doing.
Wait, I thought the bigger they are, the more likely it is they work in IT? I kid, I kid...
To be fair to the IT guys, this is true throughout the entire organization. Granted IT guys' personal, err, shall we say, quirks, only amplify the problem.
"If you don't give me a spec, whatever I give you meets spec."
Yeah, let's skip the whole, maybe-I-should-ask-the-customer-what-it-is-they-want business and just jump right in!
say it, mean it and give em a lot of shit when they balk at the end result. Next time, they find time for the non coding parts of the SDLC.
Next time they hire somebody else.
Saying software is "Too complicated" is usually a cop-out by the users and the managers that are involved in purchase and/or use of that software.
Yeah, god forbid you'd ever want to take the end-user's opinion into account. Or wait, maybe that's the cause of bad software--devs write to what they want and not what the users want.
I'm a software trainer. We spend probably 25% of our time collectively laughing at bad software practices and wondering out loud who on Earth thought that widgetX was a good idea. The cop-out is on the developer's side, not the user. If something doesn't work well or is overly cumbersome and there's a better way to do it, the user isn't copping out, the developer (or the Program Manager, or the SE, or whoever made the decision not to make the software better) copped out.
Did you RTFA?
This is slashdot, right?
I assumed GP was going for a +11 funny
To have a right to do a thing is not at all the same as to be right in doing it
Well said. I think most users' frustration comes from the fact that most (anecdotal) companies err too far on the side of security. Example being my current prime contractor requires us to send emails encrypted, even the most mundane, yet seemingly every other day somebody's cert is out of date, incompatible, broken, whatever. It makes it impossible to do work. Instead, I pick up my unencrypted telephone and talk to the person.
Another anecdote would be the ridiculous 15 character, two upper, two lower, two numbers, two special character password requirement just because ONE of our customers (not one I work with) is military and that is the military requirement. It changes every 45 days and can't be the same on any one of the three networks I use. Yeah, right, of course I'm not gonna write down any of the three 15 character passwords anywhere in any of my notepads anywhere.
Your reading comprehension falls below zero. You must be on the business side of things, not IT.
Ok, I know this isn't FTA, but the headline just made me angry. I have friends in the medical and banking industries and I hear stories from them all the time about how much work it takes for them to make sure that information is kept private. I work for a government contractor and I spend almost my entire day making sure our systems are secure. Truth be told, it isn't cheap to keep people's information secure... BUT WE DO IT!!! What is the result? You rarely hear of a data breach on these industries that involves a good hack. Breaches are usually limited unless it's an inside job. Now, there isn't a vendor of any good I know who has decided that information security is something worth paying a dime for. I hear everyone from lawyers to corner-store shop-keepers tell me it's too complicated and expensive to implement basic security (like putting a password on their WAP) or even a decent backup system (like an external HDD and some backup software). In the end, WHEN these businesses have their data leaked and WHEN they lose their DATA, WE ARE ALL PAYING FOR IT!!! If you are a vendor and you are reading this, remember this: if you tell me (or possibly any IT person) these excuses, all we hear is that you are CHEAP and LAZY.
Mod me down, I shall become more off-topic than you could possibly imagine.
I'm a software trainer. We spend probably 25% of our time collectively laughing at bad software practices and wondering out loud who on Earth thought that widgetX was a good idea.
So...I take it you get a lot of business from companies who insist on forcing their employees to use Bloatus Goats, er, I mean Lotus Notes?
Yet another example where the devs are big fans because 'it can do so much more than just email!', but the actual user is left in a mess of pain trying to use the end result for what they need it to do...which is, 90% of the time, just frigging email...
"I love animals! Some are cute, others are tasty, what's not to like?" - Betsy Schroeder, Jeopardy contestant
If part of their job involves working with sensitive data, protecting that data IS part of their job. Understanding how to use the tools necessary to provide that protection IS part of their job. But many people think that learning such things is beneath them and that it's IT's job to figure out how to design a system that doesn't require thought or comprehension.
I used to work for a company that built the absolute #1 MVS security product. It was great because through it and its very flexible rules specification you could ensure that users only had access to files and resources they were actually supposed to have access to. Sounds wonderful, right?
Except for one little problem. It was incredibly difficult to set up. Let's take your average medium-size company. How many individual files do you think there might be on on-line media? Millions is probably not an exaggeration. Can you imagine crafting a rule for each file? How about imagining crafting a generic set of rules for files in specific places in a heirarchy but having to deal with exceptions that nobody thinks of until the user is blocked?
Just to get that MVS security system up and running at all generally took a year for most users. I would expect nothing less for what is being described here because it is pretty much the same thing. The result is that this is the sort of project that never gets finished and keeps getting put on the back burner.
It has nothing to with the complexity of the software but everything to do with the complexity of what is needed. Trying to define roles of users and the access to resources they should have after the fact is very, very time consuming and will result in a lot of failures. A failure means disruption and can mean failure to comply with some regulation which results in a fine. Can you imagine that this isn't something real popular with upper management, even when they mandate the implementation?
Yes, I see. Your lack of people skills is what is prohibiting my comprehension, evidently. Care to elaborate on my reading skills further?
You said, without specs, you'll just go off and make whatever you want and then the customer has to accept that, which is a horrible practice, and not at all how business works between a supplier and the customer. You should never start a single line of code until the requirements are hammered out, in place and agreed upon by all parties. Best case you might provide some nice ideas they like and accept, worst case is you do a bunch of work that you won't get paid for. And with your attitude, they won't hire you back either.
So you complain that the software doesn't have default cooking instructions programmed in that would just magically make cookies or cupcakes without you having to do all that extra work.
Yah actually, that is what I'm complaining about. I want a cupcake, I'll settle for the recipe, but just the ingredients? Thanks for nothing.
Example: LDAP, Kerberos, DNS vs.
Active Directory
Sure, you _could_ use the above technologies to accomplish what AD does, with a ton of time, and still not get to the point where ISVs can even dream of integrating with it. There are an infinite number of ways to implement an authentication/delegation/identity/system management/configuration management/service advertising solution etc., and then there is Active Directory. The cupcake won.
The problem is that the users can't be bothered figuring out what they want, so the software is at fault.
See, that's your problem right there. You can't just ask the users what they want.
Steve Jobs was right when he said this "You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new."
My favorite illustration of this mistake is the Homer Car http://simpsons.wikia.com/wiki/The_Homer
That is the wrong way to design _anything_, including software.
If you can't figure out how to turn your pile of crap ingredients into a cupcake, then what chance do your customers have? That is what "box of ingredients" software tells me, the authors have no idea what to do with it.
Yah actually, that is what I'm complaining about. I want a cupcake, I'll settle for the recipe, but just the ingredients? Thanks for nothing.
All you have to do is tell it the recipe (ingredients plus instructions) and it will give you a cupcake. But the users want to just say "cupcake" and have one magically appear. Sure, they could have defaulted the software to make everything a cupcake, but then the guy that wants banana bread will complain that he got a cupcake instead. He could have checked the box for "bread" rather than accept the defaults and complain about them, but that's what he did.
What you are proposing isn't a development project to explicit requirements. What you are proposing is a psychological experiment trying to predict what people will want 2 years after the project is over. That's fine and dandy. People do that. But that isn't software development. It's stupid to do so for a development project. When you get it done and the person who commissioned it says "I requested it do XXX" and you respond "I heard you, but I know you are an idiot user, so I excluded that feature because you'd really rather have YYY instead." I'd expect employees following your advice to be fired, and consultants following it to be sued.
If you can't figure out how to turn your pile of crap ingredients into a cupcake, then what chance do your customers have?
The customers don't even know they want a cupcake, and if they did, wouldn't be able to tell you what one is, just that what you gave them wasn't it. You aren't advocating sound development processes. You are advocating Development By Ouija. Whether that works for Apple is irrelevant to the question of whether that's an acceptable practice for software development. And it's most certainly not an acceptable practice for software development.
Learn to love Alaska
We can argue the theory until we are blue in the face, but we can't ignore all the good software out there and the reality of what separates winners from losers.
There is a clear trend, "Let me show you how you should be doing that." and general ease of use.
We wouldn't be having this discussion if Data Protection Software wasn't a PITA to use. You can blame the customer and we'll be back here a few years having the same argument over why people still aren't using it correctly, or at all. Or, someone will figure out how to bake Data Protection Pie and steal everyone's lunch. /food
The posts you reply to are by two different authors.
Clearly, you haven't read the thread. I see your generally negative posts all over. Trying to bump your karma count so you can use this account to moderate your other accounts? You smell like a troll to me.
All QoS software is a PITA to use. Why? Because QoS, as a concept, is hard. When the concept is hard, it is necessary that all implementations that are powerful must necessarily be as hard to use as the concept behind them. Making it more simple is possible, but necessarily removes capabilities.
Your argument is that Mathematica is bad software because math is hard. Or that if I can't make an accurate flowchart in some software program that the fault is that of the software maker because they should have help that guides me to the correct answers. GIGO. And if the developers aren't smarter than every user combined, then the software must either be extensible in some way (and thus "hard" since you asserted that requiring any useful input from the users makes it necessarily poor software), or the users are a bunch of morons better suited to crayon and colored paper (and maybe some safety scissors, but I'm not so sure about that, you can still cut yourself with those if you really try).
Learn to love Alaska
As a member of the Department of Defense community, security becomes a way of life. In a fast-paced, highly classified operation "too complicated to use" is an unacceptable excuse. So, a built-in, systems approach is used, including hardware, software, and human, i.e., physical. The organization does need a security officer or administrator for surety. All that leaves you to deal with is your mission critical stuff, physical security and document protection. Thus "operating" data protection software never is an issue. A piece of cake? Never!