Slashdot Mirror


Fixing Security Through Obscurity?

LineNoiz asks: "I work as a junior developer at a small company that sells check printing software. One of my company's favorite things to tell customers is how secure our product is and how it will reduce check fraud (we even sell check fraud insurance). I cringe everytime I hear them say it, because I know that it is 'secure' only because of it's relative obscurity. I personally know very little about security, and really have no idea what it would take to make our product secure. All I really know is that this is a problem waiting to happen. How can I convince my managers that our security is nothing to brag about? How can I convince them to spend the time and money to make it secure? Where can I myself go to learn more about security and what it would take to make/keep it secure?"

6 of 66 comments (clear)

  1. Hmmmm.... by zulux · · Score: 5, Funny

    You're an underpaid jr. developer....

    Your company makes check writing software.....

    You want to show them that their software is insecure....

    Your Poor. They have checks. Things are insecure.....

    Hmm....

    --

    Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.

  2. Sounds like a very secure system to me by MerlynEmrys67 · · Score: 4, Insightful
    As a customer, I use your software - if there is a vulnerability, your company comes back in and reimburses my costs for the vulnerability... Sounds perfectly secure to me ?

    Go and write a million lines of security software and don't provide the guarantee - it isn't worth as much to the customer.

    What you have to realize is that it is an easy equation for your company

    How many reimbursements do they have to pay out on an annual basis. vs. How much will it cost to lower that number.

    I am betting they are paying out pretty close to 0 in reimbursements (which is why they are advertising this)- how much of your salary will it take to make the product even slightly more secure ?

    --
    I have mod points and I am not afraid to use them
  3. Re:convincing the managers by innosent · · Score: 5, Informative

    What exactly is ever secure about a check? He says it's a check printing company, so what could possibly be secure about it? You can order printable checks from just about anywhere, with all the "security" features on them, get a MICR toner cartridge (if you even care when the bank complains about having to hand-enter your checks because they're not magnetic), and print all the checks you want. This is probably just some kid who's finally figured out how banks operate.

    "Security" features on checks usually are only to prevent someone from photocopying the check, and do nothing to stop someone with a box of checks and a laser printer. No matter what you do while printing the check, Checks are not secure. Most businesses print their checks, and print them in the same manner as I just described, and there is nothing that can be done about it, because banks will cash any valid check, which means only that the account number and signature must match their records (you could write the information on a napkin and the bank would take it, it is a valid check), and banks will rarely flag a check for a bad signature.

    If someone gets one of your "secure" checks from a client of this guy's company, orders a box of checks from them, and prints checks, then even the client may not realize that they didn't write the check. That's how checks are, deal with it. If you don't trust the person you're writing a check to, don't use a check, it's just that simple. By the way, it is amazing to me how the banks always say "don't give out your account information to anyone" (and no, I'm not talking about PINs) when it's printed on every check. The only thing worth making "secure" (as in unable to be scanned/photocopied) about a check is the signature line, and very few companies do this, since the only effective means I know of to do this requires a color laser printer and an electronic signature image. (red/black printing scheme, etc).

    --
    --That's the point of being root, you can do anything you want, even if it's stupid.
  4. Re:Just forget it by mikehoskins · · Score: 4, Informative

    I think this is the best response I read.

    One thing to remember, you are a junior developer and you will rock the boat if you are not walking-on-eggshells-careful. This is true even in a good economy.

    Trust me, I used to rant about things broken in IT. I was respected for having a lot of knowledge and insight in IT. However much I still believe I was right, I learned, years later that attitude and patience will pay off more than brilliant ideas.

    An old saying has to do with attracting flies with honey. Learn that and learn all you can about security on your spare time, to buttress your claims. Show them how good and knowledgable a worker you are, to convince them your opinion is valid.

    Don't tell them they are wrong. Just factually show them how they could improve.

    (I wrote this in about 3 minutes, so if it doesn't appear coherent, read it again, without mentally spell checking and grammar checking. Sorry about the clutter.)

  5. Specifics by greenhide · · Score: 4, Interesting

    I cringe everytime I hear them say it, because I know that it is 'secure' only because of it's relative obscurity.

    By "obscurity", do you mean it's not a well known product?

    I'm going to jump out on a limb here and guess that if you're going around making check software, then someone in the company actually spent a number of minutes x (with x >> 5) thinking about security in the product.

    Here's an idea. You're a junior developer, right? Why not sidle up to a senior developer and say, "Hey, can we talk for a moment?" Tell them you've recently become interested in security and learning more about it. Ask them what the current security for your products is. If there isn't really any, ask them if they know if competitors use any kind of security features, saying something like, "I'll bet it would make our product look better if we could tell potential customers that we use x, y, and z to make our products secure." If he or she doesn't sound interested, evaluate how this makes you feel about working there. It probably isn't a good idea to make this a crusade; it'll just make you look mean spirited if you push through your senior developers. You can choose to stay in the company, knowing the product isn't fully secure, or if security is your thing, you can move to a company that's more secure.

    Think about a worst case scenario: someone writes a series of checks that are bad. That's not impossible to happen with normal non-computer generated checks anyways. It could potentially be a lot of money -- perhaps -- but credit card fraud is generally a lot easier to perpetuate. Most check fraud that does occur is people writing big checks on their own accounts that bounce, or it's people just forging checks, neither which you or your company have any part in.

    If you were in a company storing electronic medical records or bank accounts, then security through obscurity would be pretty catastrophic. But I'm guessing that you're blowing this out of proportion.

    --
    Karma: Chevy Kavalierma.
  6. Do your homework by swillden · · Score: 4, Informative

    Developers, especially young ones, often see things that they think need to be changed, and get frustrated when management seems to ignore their concerns. In many cases, the techies are actually right, but they don't understand that (a) there are many, many issues to be considered that they don't know about and (b) simply claiming that a problem exists isn't enough. You also have to communicate the problem and its solution clearly and effectively, without rocking the boat.

    The solution in all cases, not just in issues of security, is to do your homework. When presented with a thoughtful, detailed, documented analysis of a problem, its potential *business* impacts, and a recommended solution, managers generally do take note.

    In this case, if you really care about the issue, there are some things you can do that will almost guarantee that you'll be listened to:

    First, you need to both educate yourself and construct and analyze a threat model. The "education" in question is more about business and risk analysis than, say buffer overflows and leaky protocols, and the process of building and analyzing the threat model will give you a lot of it.

    A threat model generally consists of the following major areas:

    • Potential attackers. Identify and document all of the categories of people who might wish to attack the system. For each potential type of attacker, outline as thoroughly as you can the attacker's motivations, access to the system, capabilities and tolerance for risk.
    • Risks. Identify and document all the kinds of risk to your company's *business* that you can think of. Are there any ways an exploitable system could cause direct financial losses? What about damage to the company's reputation? In the event of an exploit, will the company be financially liable? This means you also need to explore and document risks to your company's customers.
    • Avenues of attack. Identify and document all of the different ways in which the system could be attacked. You don't need to identify particular weaknesses, just categories of weaknesses. Be sure that you don't focus solely on technically-oriented attacks. If there's an easy-to-perform, hard-to-trace non-technical attack that no one is bothering to exploit, it's very unlikely that an attacker will bother with trying to break the technology.

    After you've created the threat model, you need to analyze it. To do that, you need to try to quantify all of the elements of the model. In the business world that ultimately comes down to assigning dollar values to everything. For each attacker, try to figure out how much they could steal by attacking the system. Even harder, try to quantify the value of attacks for ideological reasons (if any). For each risk, quanitfy how much the company stands to lose if the risky situation happens. For each avenue of attack, try to quantify the cost of performing the attack.

    Once you have dollar values for everything (many will have to be expressed as ranges, and all will be built on guesswork), look to see if there is any combination of motivated attacker, risk and avenue that looks like a "good attack". That's an attack in which it's in the attacker's best interest to perform the attack, taking into consideration the possible negative effects as well as the benefits, the attacker's motivates, access, resources, etc.

    Think long and hard about all of the good attacks, try to assign probabilities to them based on everything you've learned (plus another crapload of guesses, of course) and you should able to come up with an expected cost for each of them.

    The last stage of the analysis is to try to guess at the cost of fixing them. Don't even bother trying to think about financial "benefits" of fixing them... "You can tell all the customers that its *really* secure!" doesn't mean much because they can *already* tell the customers that. It may not be true, but you're wandering into marketing, where truth is... flexible.

    You're not

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.