Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Balancing Bad Applications vs. Network Security? 93

Darlok asks: "One of our clients recently purchased a new financial software package from a major vendor for their industry. This is not a small mom-and-pop software house. The problem is, like a lot of industry-specific software, there are a considerable number of bugs. What's shocking is that to work around a problem preventing users from logging on, the manufacturer's recommended solution is to grant -Domain Administrator- privileges to all users, and they refuse (or are is unable) to explain that need further (it's bad enough that an increasing amount software seems to require local administrator privileges). Considering the enormous costs involved, how do you explain to Management that they shouldn't run this software until the problem is resolved -- which could be a long time, costing even more money? How do you balance productivity versus security when ANY productivity would give away the keys to the city? What can make an industry-specific software manufacturer pay attention to larger issues when they already have something of a captive audience?"
This discussion has been archived. No new comments can be posted.

Balancing Bad Applications vs. Network Security?

Comments Filter:
  • Simple terms. (Score:5, Insightful)

    by babbling ( 952366 ) on Thursday March 16, 2006 @09:37PM (#14938447)
    Management doesn't want to know the details. Just say there are 'major security concerns'.

    You shouldn't usually sacrifice security for productivity, unless you don't need the security. I suppose Windows is a good example of businesses sacrificing security for productivity, though. In most cases they probably get away with it by having firewalls and the like.
    • Re:Simple terms. (Score:5, Insightful)

      by secolactico ( 519805 ) on Thursday March 16, 2006 @09:53PM (#14938544) Journal
      Management doesn't want to know the details. Just say there are 'major security concerns'.

      Explaint to them that granting domain admin priviledges to everyone means that even the interns they hired to do data entry will have *full* access to every resource on the domain. That includes servers and workstation with sensitive information (incl. upper management's). And that it's just a matter of someone getting up to to go to lunch and not locking their workstation to leave the door wide open to any passerby.

      Problem is, by now your data is in this tool and you need to use it to work. So you'll have to bite the bullet anyway.
      • Re:Simple terms. (Score:5, Insightful)

        by Philip K Dickhead ( 906971 ) * <folderol@fancypants.org> on Thursday March 16, 2006 @09:58PM (#14938572) Journal
        Explain to them that they cannot acheive SOX compliance, and that violations are punishable by jail-terms for responsible c-level officers.
        • Sig (Score:1, Offtopic)

          by XanC ( 644172 )
          Okay, this is off-topic, but I'm confused. Not that I'm saying I disagree with you, but when somebody places his hand on the bible and swears an oath, he's attesting that he means it because he believes in justice in the afterlife.

          Basically, it means the Bible is more important than the Constitution.

          So how does pointing this out help your case?

        • That, sir, is pure genius. I'm stealing that one the next time something like this comes up at my work.
        • You've given a one line answer which will carry the argument in the majority of situations... well done. Just mentioning SOX should be enough to bring managers out in a cold sweat :)
    • Re:Simple terms. (Score:4, Interesting)

      by mork ( 62099 ) on Friday March 17, 2006 @07:23AM (#14940641)
      You need simple analogies to explain this to management.
      In the next meeting ask the boss for his house keys, then proceed to explain that you will now make copies of his house keys and along with directions to his house pass out the key copies to all employees.
      When he freaks out explain this is the same as granting domain admin access to the systems.

      That should help explain the importance of security :)
    • You shouldn't usually sacrifice security for productivity, unless you don't need the security.

      Not true. Computers owuld be more secure, and a lot less productive, if they weren't networked. Everything gets compromised
  • by Marxist Hacker 42 ( 638312 ) * <seebert42@gmail.com> on Thursday March 16, 2006 @09:38PM (#14938458) Homepage Journal
    A reasonable option in this situation is to give the experts who will use the industry specific software their own subnet; and save all files to a shared server that then backs up to a server on the regular LAN. The only point of contact should be that file transfer protocol- NOTHING else should be allowed through. Then hire an IT guy to help out the experts, and leave it at that.
    • Yeah. Or isolate on a Citrix / Term Serv box, and buplish only over ICA/RDP.
    • by mosel-saar-ruwer ( 732341 ) on Friday March 17, 2006 @03:20AM (#14940036)

      A reasonable option in this situation is to give the experts who will use the industry specific software their own subnet; and save all files to a shared server that then backs up to a server on the regular LAN.

      If this financial software package is as expensive as "Darlok" makes it out to be, then just go to your local Microsoft rep and purchase a bunch of seats for a new Domain - the cost of the new seats would probably pale in comparison to the cost of the financial software package.

      Then let their secondary accounts all be Admins within their own little domain, but with no special rights to the larger Active Directory tree.

      Or do that old thing with NT 4.0 Domains, where Domain A trusts Domain B, but Domain B doesn't trust Domain A.

      Or create two separate domains entirely [with no ambient Active Directory tree and no trust relationships], and just make everyone memorize two different user names and two different passwords.

      That'll get management's attention.

  • by MagicMike ( 7992 ) on Thursday March 16, 2006 @09:42PM (#14938481) Homepage
    Definitely try to whip the vendor into shape, but have you considered running the application in a quarantine area, like a VMware VM?

    It's trivial nowadays at least to set up separate little compartmentalized computers and networks, though I recognize that the carry-cost (virtual services are still supported services and need monitoring and troubleshooting and backups, etc etc) it would at least get around the privilege issue.

    If this is totally non-helpful, sorry, it was the only thing I could think of :-)
  • Sounds familiar (Score:4, Interesting)

    by karlto ( 883425 ) on Thursday March 16, 2006 @09:47PM (#14938512) Homepage

    We were told something similar with a new software package... turns out that a single registry key needed slightly different permissions. I wasn't too impressed with their suggestion that all users need to be administrators either!

  • by RingDev ( 879105 ) on Thursday March 16, 2006 @09:49PM (#14938518) Homepage Journal
    I have my own nightmeres from trying to support a 3rd party app like that. At this point I would suggest investigating the issue as much as possible. Set up a file request watcher(MS has one, but I can't recall its name), a port sniffer, keep an eye on the Active Directory. Log into the system and see what resources are being access that could require that kind of access. Is it updating the AD or trying to use LDAP? Is it performing some process remotely on the server? Is it trying to create/share/access some sort of network resource?

    Find out what it is trying to do and open security only for that action to the users.

    -Rick
    • You could also create a domain for users of that application only. Use VLANs and install a small domain controller. Prevent any cross-contamination between the two domains.

      After that, just let the users have at it. Most likely, they won't fuck up too bad. And their curosity to go sniffing around will be sated once they find that all that's out there is X-number of PCs exactly like theirs. No e-mail. No personal documents. No pr0n.

      Give those users a laptop or another desktop with a KVM switch so they
  • Let's name NAMES (Score:5, Informative)

    by Philip K Dickhead ( 906971 ) * <folderol@fancypants.org> on Thursday March 16, 2006 @09:54PM (#14938548) Journal
    Oracle.

    This is a big issue. IANAL, but I think there is a legal casse here. You may have signed this away by contract, so...

    Under this configuration, there is no way that you company - if publicly traded - can meet the mandated compliance under SOX, etc. This doesn't touch the fact that you have now lowered authorization and access controls to a level that is inferior to MS-DOS.

    And why does the DB vendor care? They assume all value is locked under their own controls - and the OS is insignificant. Bad shot. If you are a domain admin, you can always work your way into something - even put a keylogger on the financial controllers desktop, and capture the precious secrets for logging into the system.
    • >Oracle.

      Exactly what product does Oracle require this permission?
      • I am just mitigating an oracle financials app that is hard-coded to have read/write access to files in the windows/system folder. Locally and on the server! Yowch.
        • That still doesn't require domain access, just local read/write access to the local system folder and the server folder. You should also check to see if the server file activity is under the user's account or under the service account running on the server.

          -Rick
          • You and I know that - but the solution of the consulant who built this was to add DOMAIN USERS to DOMAIN ADMINS.
            • by LurkerXXX ( 667952 )
              So it isn't actually Oracle that is the problem, but moronic consultants. Lay the blame where it belongs.
            • "DOMAIN USERS to DOMAIN ADMINS"

              Then the consultant is a MORON. If giving users Domain Admin access is the ONLY possible solution (which I highly doubt) there is still no reason to give the entire Domain Users group Domain Admin access. You would still only increase access for those users who need it. If we're going to name names, what is the name of the consultant who told this to you? Just so I know to make sure I don't inadvertantly wind up hiring him.

              -Rick
              • This was someone who'd been at the customer over a year ago.

                Whacking bad problem! All c$ shares and remote registry available to everyone, everywhere on a flat network! Even PT security guards in the middle of the night.

                I don't know how they missed a worm infestation.
    • This doesn't touch the fact that you have now lowered authorization and access controls to a level that is inferior to MS-DOS.

      No kidding! A domain admin can set security policies that effectively prevent *anyone* from logging in, and propagate those policies to all the workstations on the domain, thus disabling local logins on every machine in the company! All it takes is one malware program...

    • Another NAME (Score:2, Informative)

      by Anonymous Coward
      Sage Software(formerly Best)

      Full read/write permissions in the Windows folder for Crystal Report libraries.
      Full read/write permissions on the program directories.
      Disable real-time virus scanning of the program directories.
      The read/write permissions aren't even documented because you can--and this is a direct quote from support--"just make the user a local admin."
      • I have had to accept Local Admin for their WS. This is done by machine GPOs, with a machine startup script that add them for the duration of the session:
        NET LOCALGROUP /ADD Administrators INTERACTIVE

        They are local admin, until logoff. This doesn't extend the privilege to any kind of Remote Auth (unless you count terminal services), and the user can't access C$ across the net to another host where they may also be logged in.

        It's a compromise, and I noted the risks in my report.
  • Use an analogy... (Score:4, Insightful)

    by fredklein ( 532096 ) on Thursday March 16, 2006 @09:55PM (#14938552)
    how do you explain to Management that they shouldn't run this software until the problem is resolved

    "What would you do if you got the door to the breakroom replaced, no one could open it, and the manufacturer's solution was 'Give every single employee a copy of the Master Key for the entire building'?? Well, it's 100 times worse than that."
  • Jail it off (Score:5, Informative)

    by 19thNervousBreakdown ( 768619 ) <davec-slashdot@l ... t ['the' in gap]> on Thursday March 16, 2006 @10:01PM (#14938594) Homepage

    Speaking as someone who has had to support software written by people with no concept of security, if it is even remotely doable, even if it means a fair amount of work, take that machine off the domain. Jail and firewall the everloving snot out of it, don't let any data into it except through very controlled routes, and don't give it any privileges on the network, then give it all the admin rights it needs. Basically, just change it from a piece of software into an entire dedicated appliance.

    Although you could spend the time to try and fix their problems, this kind of thing will come up over and over again. You'll save yourself time and effort if you nail it down now.

  • Difficult situation (Score:5, Informative)

    by QuestorTapes ( 663783 ) on Thursday March 16, 2006 @10:02PM (#14938598)
    Note: IANAL

    > One of our clients recently purchased a new financial software package
    > from a major vendor for their industry.

    When a business purchases software (or anything else) the manufacturer implicitly warrants that the item is suitable for its intended purpose.

    > What's shocking is that to work around a problem preventing users
    > from logging on, the manufacturer's recommended solution is to grant
    > -Domain Administrator- privileges to all users, and they refuse
    > (or are is unable) to explain that need further

    Time for the client firm to call in the lawyers. Write up a formal document explaining that this is unacceptable from a security standpoint. Period.

    That your firm cannot and will not accept -any- responsibility for anything that goes wrong if the client's management uses the software in this fashion.

    Then write up a formal recommendation that the company either (A) sue the vendor or (B) place the payment for the software in an escrow account, and explain it will be turned over in payment only after the software is made usable by fixing the defects. Choice B is a standard option in dispute resolution; it demonstrates that the client party has every intention of paying, but not until the responsibilities of the vendor are met.

    Have -your- firms lawyers look over all these documents and recommendations carefully, and put the right spin on it.

    > Considering the enormous costs involved, how do you explain to Management
    > that they shouldn't run this software until the problem is resolved --
    > which could be a long time, costing even more money?

    Lay out the business details. Explain to them that under current federal law, the -management- of the client firm will be assuming any an all liability for using unsecure software against all the recommendations of your firm's people.

    However, even with all this, the client's management may choose to give away the keys. Cover your own asses. If you support the client in this, you may be liable. In situations like this, the client may choose to go full steam ahead; you can't stop them, you can only CYA.

    • When a business purchases software (or anything else) the manufacturer implicitly warrants that the item is suitable for its intended purpose.
      You haven't read an end user license agreement lately, have you? In all the ones that I have seen the manufacturer doesn't guarantee that the software will do anything, including its intended purpose.
      • > You haven't read an end user license agreement lately, have you?

        Actually, I have. ;>

        > In all the ones that I have seen the manufacturer doesn't guarantee that
        > the software will do anything, including its intended purpose.

        The law (in the US) doesn't permit a person to waive -all- legal protections under licensing agreements. These kinds of dodges in license agreements are generally held to have limited effect on software designed and marketed for business purposes.

        I'm not saying it's a slam-du
    • LOL - Lexis Nexis (Score:1, Interesting)

      by Anonymous Coward
      Your comment would have been helpful had your lawyer's firm not been totally owned because the Lexis Nexis firm management software that they rely on works in exactly the same fashion.

      Administrator privileges required on the workstation, sucks but common. Administrator privileges required on the server, totally ridiculous and unacceptable but, also increasingly common.

      The moronic developers sales droids of these apps say; 'Oh, don't worry, we have security built into the application.' Translated, this means
  • Speak their language. Management types, around half the time, hear "security concern" and think you're some overstuffed loser with delusions of grandeur, afraid of THE HACKERS who care, at all, about your data. The other half are of the same ilk, but think you're suffering from a guilty conscience and are the "hacker" they need to worry about. Instead, warn them the security risks open the way for buzzword storms. Viruses! Worms! SPYWARE! SPAMMERS! Crashing servers! Cats and dogs, living together!
  • Very easily fixed (Score:3, Insightful)

    by Anonymous Coward on Thursday March 16, 2006 @10:16PM (#14938672)
    Put the application in its own domain.
    • VLANs are your friend. KVMs are useful too. Problem solved...
    • But it doesn't address the fact that every user of the system (assuming a DB of some sort here) would be able to go in a screw up the application. If everyone using it is a domain admin, then they are able to change everyone else's passwords, then log in, scew with the data, and leave. They may not be able do that outside that particular domain, but now that application is still useless cause you can't trust its data.
    • Your "solution" of creating a separate, isolated domain for the offinding application is completely inappropriate. It reminds me of when the police did a crackdown on prostitution in a notorious inner-city neighbourhood in our city. On the surface they were very successful--hookers and Johns are dramatically less visible in "the beltline" now, and the developers are falling all over each other to buy out all the slumlords, tear down the decades-old shacks and put up shiny new executive condominiums.

      In rea
  • by ErikTheRed ( 162431 ) on Thursday March 16, 2006 @10:18PM (#14938689) Homepage
    Here are some ideas you (and your management) can pursue, simultaneously if need be. Oh yeah, IANAL, but I've dealt with plenty of them.

    1) See if you can figure out what requires Domain Admin access - usually it's file or registry issues. SysInternals RegMon and FileMon are excellent for spotting these - you just run the program with regular user privileges, and watch to see which requests fail.

    2) If this is a large, contract-licensed piece of software, look to see if the contract's been breached. Even if the vendor indemnifies themselves thoroughly, a good lawyer might scare them into compliance - you never know which contract provisions a judge may find unenforceable. I've seen really strange things happen in court (both good and bad). If you're working with the vendor, you can use the "look, you've sold us unusable software - you have to either fix it now, or I have to turn this over to legal so they can get our money back, and try to recover compensation for the time and resources we've wasted" card. Don't rant and rave and scream and threaten - just be a nice, reasonable person and explain that they're not leaving you any alternatives. You need working software or you need compensation. Only a very stupid or very cocky vendor will refuse to work with you - nobody wants to be dragged into court. And you really don't want to go to court either, but you can't afford to get screwed

    3) Another possible route is to get them to put in writing that their software will only run with Domain Admin priviliges or whatever. Tell them you just need it to cover your own butt. At that point, you can get your management to sign off on it as well, thus covering your butt completely, or your management can use it to help show they negotiated in bad faith while selling your company the software.

    Whatever you do, don't let a vendor bully you into doing something stupid that violates your responsibilities as an admin.
  • Speaking as someone who has to implement any number of crazy last-minute apps before processing millions of documents, the last thing I want to worry about is conflicting credentials and other security bullshit. Now obviously "Domain Administrator" is a pretty extreme example, but I recently had a half dozen critical machines down because some do-gooder idiot renamed the Administrator account and didn't give me the new password OR account name. ARRRRRGHH

    These machines might as well be in a vault in the Bank
    • Every single place I've worked has lost more time/money/data to security measures than to breach of security.

      Makes you think.

      • Being IT Manager for a financial company, I know what you are talking about. Users are always coming to me complaining about the complex passwords they have to remember, and the way they can only get to the systems when they are logged in locally, not from home or from a remote site. "Its not as if anyone has hacked in" they tell me.

        And that is my vindication that the security measures are working. I would be worried if they had lost more time/money (data is debatable) to a breach than security measures.
  • by Pig Hogger ( 10379 ) <pig.hogger@gm[ ].com ['ail' in gap]> on Thursday March 16, 2006 @10:42PM (#14938829) Journal
    In business, more than anywhere else, you have to know how to say "no". Sometimes you have to terminate a customer. This could be a good opportunity to do so.

    Enjoy.

  • Is it feasible to set up a domain for the software to run in? It's not a good answer, I know, but it may work, and the costs involved will probably be trivial if the software is critical enough.

    I must admit, however, I'm having an incredibly hard time imagining what this software could be doing that requires Domain Administrator privileges. Poorly written doesn't even cover it.
  • Several people have already pointed out the legal issues re: SOX compliance when installing POS software like this. Another piece of advice is: if they don't listen and insist on installing this package, fire the client.

    Some clients just aren't worth keeping. Ones who don't take your advice seriously, and are willing to do things that will put themselves, and possibly you, in legally precarious positions, just aren't worth hanging onto. If they insist on going this route, and you've done everything you can
  • Here is an honest answer...

    I'm pretty sure you are not talking about the kit I've worked on, but I sure know the type. My bane is DBA's *love* to screw with stuff because we allow them to manually run the setup if they like. Some claim it is to improve performance, some security... All in all, it makes for obscure errors and headaches later on when additional components are added to the system. It costs money to make a specific environment 'tested' year after year with all the possible permutations. Yes
  • "... they refuse (or are is unable) to explain that need further..."

    Maybe they want complete control over your computers remotely at all times. If they decide to put you out of business, in favor of a competitor, they can change their EULA (which they usually say they can do at any time) and uninstall or corrupt their software.

    --
    The movie Loose Change, 2nd Edition [google.com] explores 9/11 issues.
  • by Skapare ( 16644 ) on Friday March 17, 2006 @12:11AM (#14939349) Homepage

    There is a simple solution to getting the problem fixed. Just post the name of the software package, software company name, and link to their website. Slashdotters will ruin their reputation. And the hackers will find the network exploits that almost certainly exist in that package (and have instant Domain Administrator privilege). The company will either fix the problem or go out of business.

    • Remember what a little publicity did for Sony and their rootkit.

      Maybe the customer should remind the vendor of that.
    • You don't like free information, do you?

      Just post the name of the software package, software company name, and link to their website. Slashdotters will ruin their reputation.

      The reputation is ruined by the faulty product, a substandard OS, and a lack of information. People who need to know about the package are going to find out. Better they find out here than waste their money and vow to never buy another program from the company again. Full disclosure protects your reputation.

      ... the hackers will

  • It's Funny... (Score:3, Insightful)

    by thegrassyknowl ( 762218 ) on Friday March 17, 2006 @05:10AM (#14940314)
    ..that I have been saying for a while that software sucks. Most Windows software requires local admin rights to get anything done these days. So many wankers keep correcting me and saying "we run a large enterprise site and we don't need to give our users any admin rights".

    What they neglect to say is that they also don't give their users anymore than a basic suite of apps like Office and a web browser. When the user needs more (specialised software) there is usually an uphill battle against some anal retentive Windows admin (who should have stayed in his parents basement) and the staff who need some software that needs local admin. Usually the BOFH wins and the staff are left going without, again.

    Fortunately where I work they have realised this and we can pretty much do whatever we want. The admin understands that most users are savvy enough to not bollocks things, and most of the time things don't get bollocksed. I think I work for a bunch of wierdos though because they're the only place who will actually give me local admin on my box.

    Also, fortunately for me, I admin a Unix server so the joys of Winbites don't come up to haunt me too often... yay!

    I think that you should explain to your boss that giving users of moderate computing skill domain-level admin privs is just asking for trouble if a worm or virus makes its way into your network. Just explain that if they don't have admin rights then the damage is localised to their files on their pc. IF they have admin rights the damage can potentially spread to every PC in the enterprise VERY easily!

    Get onto the software company and cancel the cheque/credit card payment. You wouldn't pay for a car that required you to leave your garage unlocked 100% of the time. Why pay for their shit software? For a "large" operation, they certainly sound like a two-bit shit box of a company!
  • Easy... (Score:3, Interesting)

    by ebrandsberg ( 75344 ) on Friday March 17, 2006 @08:32AM (#14940812)
    Threaten to the sales guy who's commission is on the line if you threaten to sue for a defective product if they don't accept a return of the licenses. Nothing will scream louder than someone that will have to return part of his paycheck if someone else doesn't follow through with resolving a problem that is their job to fix.
    • Oh yeah, we programmer's get all choked up when a salesman's gonna lose some commission.

      Actually, I do have a couple serious things to say about this situation...

      First, what a support department says has to be done has more to do with what's easy for support personnel that with what is really necessary. They don't care if all that needs to be changed is one registry key setting somewhere, it's easier to say to make everyone an admin and you know you've sidestepped all permissions issues. I've even found
  • there are ways to enable quickbooks by giving permissions on certain reg keys.. a major PITA
  • Intuit's Quickbooks requires local Administrator priviledge for some reason. This is exceptionally annoying becuase the finance folks in many businesses are the ones with just enough computer knowledge to be dangerous.

    It is possible to get it to run without it, but it is less than fun:

    http://www.sbslinks.com/lua2.htm [sbslinks.com]
  • Needing users to be local admins is turning out to be a pain.

    Being at a hospital, we have TONS of specialized software. Every flippin department has their own contracted 3rd party stuff, and all of it sub-par software which requires users to be local admins.

    I did figure out that they don't need to be admins for Citrix though. Just a permission change on a registry key (MSLicensing) and they're good to go. But jeez...
  • Perhaps run the app over RDP on a Windows Terminal Server. Place it behind a firewall that allows RDP through.
  • Something like this happened at my work. An application required Domain Admin rights for its service account. When the vendor was pressed as to why they needed full read/write access rights to AD (schema changes, value changes, etc.) they also couldn't explain why. Their answer was that their install documentation said so.

    When their SE was onsite to do the install I asked him again why his company's application needed Domain Admin rights he was able to give one reason. During the install the applicati

  • We are running a $75M government project and brought ourselves a simple issue tracking application that cost $800 bucks

    It wasn't til I tried to get it hosted on our corporate servers ($1000/month) that we found out it requires admin rights on the server to run. Also the software requires the database and the web server have to be on the same machine.

    After spending god knows how much money testing/configuring/getting 10 managers to sign a piece of paper we said TO HELL WITH THIS - and put the application on

  • Recently I've been installing Microsoft CRM 3.0 for a customer, and I found the implementation guide quite puzzling.

    Actual requirement: "You must be logged in with Domain Administrator and Local Administrator privileges when running Microsoft CRM Setup".

    Also, two Active Directory requirements that look suspiciously mutually exclusive:
    -Active Directory must be in native mode before you can install Microsoft CRM.
    -For the Microsoft CRM servers to have access to Active Directory Organizational Units where users
  • If you have any clout and people value your opinion you can just use three simple words:

    "Not my responsibility"

    Make clear to them that they shouldn't bitch and moan and should certainly not hold you accountable for problems arising from said software after you've given them adequete warning. It may seem drastic, but sometimes you have to have a firm hand with managers to help them lose bad habits ;-)
  • RunAS Pro - users don't have to know the password for admin/domain admin, etc. App runs with needed priv's: http://mast-computer.com/c_9-l_en.html [mast-computer.com] I've used it to get a brain dead app used for Trust managment to run without giving users Domain Admin rights. Another option which I've not tried but looks very nice (and I'm sure is costly) is PolicyMaker from http://www.desktopstandard.com/ApplicationLevelSec urity.aspx [desktopstandard.com] Basically you tell management they must SPEND more money so that you can manage the ap

I've never been canoeing before, but I imagine there must be just a few simple heuristics you have to remember... Yes, don't fall out, and don't hit rocks.

Working...