• (cs) in reply to Dale Williams
    Anonymous:
    Back in the early 90's I wrote an integrated Payroll/ HR application using Clipper on DOS!

    Hey!  Another Clipper user!  I wrote a number of custom accountingish systems in clipper by day back in 1991-1992 or so (and futzing with Object Pascal by night).  There's two things I don't put on my resume any more :)   I really quite liked Clipper at the time, though.

     -cw

  • (cs) in reply to Dazed

    Anonymous:
    What is it that makes otherwise sensible people (I've met a few) shut down their brains when it comes to security issues?

     Rant no.1: The same thing that makes otherwise sensible people shut down their brain when they sit down in front of a computer: utter stupidity.

    Rant no.2: You know how many people have trouble coping with reality? Well, in the real world there is no such thing as security. Naturally, realizing this scares the hell out of your typical Joe, and scared people are bound to make mistakes.
     

    Rant no.3: Speaking of stupidity: that's how the idiotic concept of "security by obscurity" was born, after all. In other words, don't fix your broken door lock in the hope that no thief will think of simply trying the door. Which, for the less security-savvy, is what any decent thief would do in the first place.

    Pick your favorite answer.

     

  • Michael (unregistered) in reply to Anon
    Anonymous:
    Is there a site for code wtfs?  This is boring. 

    Probably...... the one your on now comes to mind.If your looking for the non-humerous variety you need to change the vocab. wtf is not a generally recognised computer term other than in specific scenarios (stories) with idiots (silly people). Caveats, pitfalls, and mongrel code are much more common for the not funny kind.Cheers,hotdog

  • (cs) in reply to CodeWhisperer
    CodeWhisperer:

    Hey!  Another Clipper user!  I wrote a number of custom accountingish systems in clipper by day back in 1991-1992 or so (and futzing with Object Pascal by night).  There's two things I don't put on my resume any more :)   I really quite liked Clipper at the time, though.

    I wrote a warehouse managment system for a warehouse with 20 or so concurrent users in Clipper(*) in 1995. Probably the single biggest mistake in my career. The Daily Index Corruption. Anyway, they've kept on using it at least till 2000.

     

     

    (*) by customer's demand, they didn't want to spend on a real database

  • (cs)

    Yeah, keeping a staff of manual-entry payroll clerks to manually enter the information is definitely the way to go. I mean, tell me who you would trust:

    1) A very small subset of relatively high-paid senior programmers with their careers and reputations on the line needing access to the test system for a short time, using test data and test accounts, with complete access controls and review available.

    2) An office of near-minimum-wage chatty data entry clerks that rotate monthly due to the low pay and the extreme mundaness of the job who are also probably not at all privvy to security best-practices (social engineering attacks, spoofed CID for the fax line, etc). Throw in a random sleeper who just happens to stay with the job for years "because they love the work environment", when in reality they're studying every in-and-out of the system and since typos do happen, "oops, I typo'd myself an extra $25k last year!"

    #2 most definitely! 

  • (cs)

    I'd hate to see this guy implement a shopping cart system....

    "No you can't do it that way because you'll have direct access to the dummy credit card numbers we've generated, what we'll do instead is offshore it to india, where customers can call up and give their credit card details directly to someone working in our call center... that will be more secure than sending it over the internet..."

  • Olddog (unregistered) in reply to biziclop
    biziclop:
    Anonymous:
    Anonymous:

    Alex Papadimoulis:
    The reports would then be entered, line by line, into the direct deposit vendor's web application by any one of the six data entry clerks hired for this process.

    Who are obviously much more trustworthy than the developers commissioned for the project.  Why is it that the developer is always the security risk, but the minimum wage temp is no threat to sensitive information??

    Um, because developers -are- in fact more dangerous, because of the skills and knowledge we have?  At one of my current clients, a fortune 50 company whose commercials you would recognize in an instant, I have implemented a back door mailout system to get files I need for the work we do for them, because the operational hurdles that they impose with their security procedures have prevented us from getting what we need - a mail account so that I can send and recieve files while I am working on the system.  They won't do this, but they leave an internal security hole open big enough to drive a truck through.  Their departmental mail server has an open relay on it, which works just fine for my needs (it's behind the firewall, so this isn't visible to the world, but if any PC in the building gets botted, this server is toast. 

    If I were malicious, I could really cause some harm. It would be a rare data clerk would ever pose the hazard that I do, because they don't have the knowledge to exploit a system weakness. 
     

    It depends on what kind of danger you fear of. If it's about deliberate destruction or theft, then yes, developers are a great risk. So are DBAs and syadmins. That's why you generally want to keep them happy and avoid those who are obviously greedy or short-tempered.

    On the other hand, management is much more dangerous. They tipically use their office laptops at home, use Windows but have no time for installing the latest patches, have little or no technical knowledge, have access for many systems, sometimes visit strange websites (nudge-nudge) and say things like "I want to read my emails at home but VPN is too complicated for me". They're the ideal source of worms and viruses at a company.


    (What if I send a spoofed fax to the data input clerks. Do they always check the sender?)
     

    Bang on target! Hooray. Seemingly odd business decision are made every day for reasons that will never be known to those whom find them odd. Not that *Faxing* is any more secure than other end-to-end process, but perhaps the risk was indeed one of the programmers. The ability to program doesn't make one any less a security risk than a financial clerk.

    For reasons unknown, the CTO opted for a system deemed trust-worthy. Most likely it was a political solution for the vendor, who didn't trust the programmers.

  • (cs) in reply to ParkinT
    ParkinT:
    Anonymous:
    Anonymous:

    Alex Papadimoulis:
    The reports would then be entered, line by line, into the direct deposit vendor's web application by any one of the six data entry clerks hired for this process.

    Who are obviously much more trustworthy than the developers commissioned for the project.  Why is it that the developer is always the security risk, but the minimum wage temp is no threat to sensitive information??

     Not to mention that fax is suddenly more secure than VPN.  Wonder if digits ever get transposed while entering the phone number they're faxing too....
     

    No problem.

    Whenever I have a fax to send that is of a "highly sensitive nature", I fold the paper before inserting in to the fax machine.   That way, if the transmission gets intercepted it cannot be read.  Afterall, there is no way to electronically UNFOLD a fax!

     


    <font face="tahoma,arial,helvetica,sans-serif">I learned this technique here... Fold the paper several times before sending it in... Compression at it's finest!



    </font>
  • (cs) in reply to BrownHornet
    BrownHornet:
    Anonymous:

    I believe this happens more often the people think.  At my old company which advertised itself as an "Technology Leader" in the industry had an automated ordering system for their clients.  What really happened after a client ordered something from the company, is that a sales rep would get the printed forms that was the order.  Then they walk it down to the Ordering Department so the order dept. reps can input it the whole order by hand. 

     As far as I know, they are still doing that today. 

    I have a similar story. At my old company, we dealt with a certain Canadian national police agency that shall remain nameless (although there is only one). When people get arrested or need background checks, they get fingerprinted and the cards are mailed to the agency, where they get queued up for human fingerprint matching experts to process, then the results are mailed back. This process typically takes 6-8 weeks. The government spent millions of taxpayer dollars implementing a system that is supposed to accept fingerprint images electronically, match them against their database, and reply electronically within minutes. After the system when into production, the turnaround time was still 6-8 weeks. Why? As soon as the electronic fingerprints are received by the agency, they print them out on a printer, process them the same way they do for cards that are mailed in, then someone manually constructs the electronic reply.

     For all that money, the vendor only implemented the part of the system that accepts fingerprints electronically and sends the replies. The part that does the fingerprint matching (which is really the most important part) will cost tens of millions of dollars more. It would be funny if my taxes weren't paying for this.

    Government IT projects have a tendency of going massively overbudget, Canada especially (remember the gun registry?).

    The sad bit is that I'm from Canada... 

  • (cs) in reply to bullseye
    Anonymous:
    Who are obviously much more trustworthy than the developers commissioned for the project.  Why is it that the developer is always the security risk, but the minimum wage temp is no threat to sensitive information??

    I'm still not sure how it's any more secure even if you could trust the data entry clerks. Any security hole in the system is still there - an intentional error in the fax still causes the money to be transferred.

    The only thing that clerks might catch is values which are much larger than usual, and then, the transaction logs (e.g. bank statements?) should be reviewed by someone trustworthy (or "higher up" in today's world) in the company anyway.

    Anonymous:
    First sign of an incompetent nincompoop. These are the folks who pride themselves in certs, awards, cutlery and other crap of no tangible value. They're good at having lunches and jumping on stages.

    Actually, MS certifications are tangible. You can touch them, and people pay good money for them - my company (over the summer) was trying to get people to take exams so that they'd have more free licences of VS et. al.

    Most qualifications, in fact, have tangible value.

    What's less tangible is skills, and experience shows that it's very hard to know how skilled someone is, except by making them do a decent amount of work.

     

  • (cs) in reply to biziclop
    biziclop:
    Anonymous:
    Anonymous:

    Alex Papadimoulis:
    The reports would then be entered, line by line, into the direct deposit vendor's web application by any one of the six data entry clerks hired for this process.

    Who are obviously much more trustworthy than the developers commissioned for the project.  Why is it that the developer is always the security risk, but the minimum wage temp is no threat to sensitive information??

    Um, because developers -are- in fact more dangerous, because of the skills and knowledge we have?  At one of my current clients, a fortune 50 company whose commercials you would recognize in an instant, I have implemented a back door mailout system to get files I need for the work we do for them, because the operational hurdles that they impose with their security procedures have prevented us from getting what we need - a mail account so that I can send and recieve files while I am working on the system.  They won't do this, but they leave an internal security hole open big enough to drive a truck through.  Their departmental mail server has an open relay on it, which works just fine for my needs (it's behind the firewall, so this isn't visible to the world, but if any PC in the building gets botted, this server is toast. 

    If I were malicious, I could really cause some harm. It would be a rare data clerk would ever pose the hazard that I do, because they don't have the knowledge to exploit a system weakness. 
     

    It depends on what kind of danger you fear of. If it's about deliberate destruction or theft, then yes, developers are a great risk. So are DBAs and syadmins. That's why you generally want to keep them happy and avoid those who are obviously greedy or short-tempered.

    On the other hand, management is much more dangerous. They tipically use their office laptops at home, use Windows but have no time for installing the latest patches, have little or no technical knowledge, have access for many systems, sometimes visit strange websites (nudge-nudge) and say things like "I want to read my emails at home but VPN is too complicated for me". They're the ideal source of worms and viruses at a company.


    (What if I send a spoofed fax to the data input clerks. Do they always check the sender?)
     

    The (incorrect) assumption is that with such a low pay scale, the type of person hired as a clerk will not have sufficient skill or intellect to compromise this information (intentionally).

  • rmg66 (unregistered) in reply to Anon
    Anonymous:

    Is there a site for code wtfs?  This is boring.

    you're boring!

  • Milkshake (unregistered) in reply to Anon

    Anonymous:
    Is there a site for code wtfs?  This is boring.

    The reality is that procedural problems are far more common and humorous.  It also allows the bullseye to be placed on several other business groups than just IT.

  • Kooky Koder (unregistered)

    "The system is still in use to this day" - If it were an "automated" MS solution, it might have been re-written 4 or 5 times by now. :)

    C winapi, vb6 .vbx, vb6 .ocx, C++ mfc client server, C++ mfc dcom, C++ mfc com+, C#, C# web svcs (soap),  Biztalk?...

    "6 data entry clerks": if it were 1 data entry clerk, I could see this solution actually being cheaper.

    But, instead of faxing, it would be more secure if they used 8 of the 16inch guns on an iowa class battleship to fire volleys of "bytes" into the water, where the splashes would be seen by sattelites and translated back into the direct deposit packet to be entered manually on the banks web site. o_O

       

     

     

  • Dazed (unregistered) in reply to Kooky Koder
    Anonymous:
    But, instead of faxing, it would be more secure if they used 8 of the 16inch guns on an iowa class battleship to fire volleys of "bytes" into the water, where the splashes would be seen by sattelites and translated back into the direct deposit packet to be entered manually on the banks web site.

    9 guns - you need a start bit. One of the guns in maintenance can be the stop bit.

  • verbal (unregistered) in reply to Kooky Koder

    "But, instead of faxing, it would be more secure if they used 8 of the 16inch guns on an iowa class battleship to fire volleys of "bytes" into the water, where the splashes would be seen by sattelites and translated back into the direct deposit packet to be entered manually on the banks web site. o_O "

    And when it rains nobody gets paid...or everyone does...or something....

     

  • (cs) in reply to rmg66
    Anonymous:
    Anonymous:

    Is there a site for code wtfs?  This is boring.

    you're boring!

    Yeah, and you're a towel!
  • (cs)

    He even manages to keep up with his prided developer certifications. At least, so he believes. A quick trip to his office would show his latest pride and joy: a Microsoft-Certified Visual Basic 4.0 Expert certificate from a little more than a decade ago.

     Ah, that explains it, he's living a decade in the past.

  • Worf (unregistered) in reply to D. T.

    Anonymous:
    The really funny thing is that when Month End comes around, we have to project our billable time ahead several hours (usually at least 4, sometimes 12) so we can get the faxes out to billing so that they can have time to enter them in.  Nevermind the fact that I touch anywhere from 4-10 projects a day...and the minute those things get faxed, they're wrong.  We probably over and under bill clients at month-end.

     I've never really understood that - considering that my timesheets are also done like that (week-end timesheets and reporting is due 9AM friday for the week). So you're left guessing what you're working on for the day, which may or may not be what you actually worked on. Month ends are the same - due the end of the month, 9AM. I've always wondered how many clients were over and underbilled for work done. And of course, no one bothers updating their timesheets after they're submitted (if you can, even). At least September has a month end on a weekend. Filling in reports twice a week gets to be a major pain. And no, even the second time no one bothers updating the first entry into the timesheet system. So it stays wrong.

     

     

  • Calli Arcale (unregistered) in reply to ParkinT
    ParkinT:

    The (incorrect) assumption is that with such a low pay scale, the type of person hired as a clerk will not have sufficient skill or intellect to compromise this information (intentionally).

     Actually, the worst bad assumption here is that the only way the system can be compromised is through a technological exploit (i.e. the sort that programmers might know how to do).  Those low-pay data entry clerks aren't touching code, but they're handling sensitive data in its raw form: bank account numbers, bank routing numbers, and dollar amounts.  This is information that would've been denied the programmers, yet apparently it's fine to let the data entry clerks look at it -- and key it in manually, day after day after day.

     And don't forget that data entry is typically a high turnover job.  It's not exactly a career, after all.  People do it for the paycheck, not for the possibility of advancement within the company.  As a consequence, you are far more likely to find someone who would be interested in making a bit of extra money by less than legal means.

    It's not a technologically sophisticated exploit; in fact, it's a very very old one that exploits the fundamental nature of banking.  But old exploits are not less effective than new ones, neccesarily.

     

  • TimB (unregistered) in reply to Ghost Ware Wizard

    Yes i agree with you.If you have a spare bullet give to me I want to shoot my ex CTO too.

     He was such an annoying bastard that  I had too give up my job and position and move on to a new place.

    TimB 

  • (cs) in reply to bullseye
    Anonymous:

    Alex Papadimoulis:
    The reports would then be entered, line by line, into the direct deposit vendor's web application by any one of the six data entry clerks hired for this process.

    Who are obviously much more trustworthy than the developers commissioned for the project.  Why is it that the developer is always the security risk, but the minimum wage temp is no threat to sensitive information??

     

    Because that minimum wage temp costs less to get rid of if they screw something up. 

  • george (unregistered)
  • Coder (unregistered) in reply to biziclop

    ROTFL... My company's policy is that laptops MUST be chained to a desk at all times! (Unless we are carrying it).

  • Zmee (unregistered) in reply to shrimp_taco
    shrimp_taco:
    I believe this happens more often the people think.  At my old company which advertised itself as an "Technology Leader" in the industry had an automated ordering system for their clients.  What really happened after a client ordered something from the company, is that a sales rep would get the printed forms that was the order.  Then they walk it down to the Ordering Department so the order dept. reps can input it the whole order by hand.   As far as I know, they are still doing that today.   

    You used to work at HP? Or was it Agilent?

Leave a comment on “The Fully Automated Manual System”

Log In or post as a guest

Replying to comment #:

« Return to Article