lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
From: cta at hcsin.net (Bernie, CTA) Subject: Re: security related contract On 5 Feb 2004 at 9:29, Eric Scher wrote: > ================================================================= > ========= > ~ "One of our customers asked us for a machine that would > ensure their local network security. Our commercial > representative came and asked if I had a solution for them. > {blah, blah, blah...}, asked what guarantees could I offer and if > I had a sample contract for such services. Now my fellow posters, > I ask for thy help. Could anyone help me with such a contract? ~ > ================================================================= > ========== > > You may not be old enough to remember Western Union Telegrams, > but on the back of the form, if you read the contract, they were > basically agreeing to ATTEMPT to deliver your message, and > nothing more. They could fail or deliver by slow turtle, and they > still weren't responsible. Keep that concept in mind. You want to > write a simple contract, don't try to fill it with legalese that > you barely understand, and don't PROMISE any results. As we all > know, there really is no absolute protection from 0-Day exploits, > other than they old "unplug and throw in the river" method that > has certain practical problems. Lets not even go INTO the End > Luser and all the problems that he/she can cause. DON'T try to > make it iron clad, because iron clad contracts can be a PITA. > Trust me. Just make a contract promising to TRY to keep his > systems healthy and secure and in a GENERAL way how you intend to > go about doing so. Do NOT promise that nothing can go wrong, > because that's exactly what WILL happen if you have promised that > it wont. > >>> I am not an attorney, but can give you sage advice based on my own experiences. CYA (Cover Your Ass). First, I would point out that many US government regulations (HIPAA, GLBA, SBOA, FDA21 CFR11, etc) require, for compliance, that work be performed in accordance with the standards observed in the industry for similar services and by personnel skilled in such services/technology. Likewise, under general contract law (US) there must be good-faith disclosure of what both parties expect. Meaning that if you fail to disclose and state what performance is expected and limited to, then in the event of a problem the customer could make a good argument that he/she expected X, Y, and Z, and only received X and Y therefore the vendor failed to perform in good-faith. For example I use the following language in my contracts: >>> Section 5.01 - Service Warranty: The service shall be performed in good-faith on a reasonable efforts basis by personnel skilled in system security and information technology, in accordance with standards generally accepted or observed in the industry for similar services. <<< Moreover, if you as the vendor/contractor fail to provide your technical services in good-faith and in accordance with accepted or observed industry/government standards, then you could be held "personally" accountable under various US privacy, security and compliance regulations. Sine qua non… Go to an attorney who knows the industry and get it in writing. I have found that www.mytechnologylawyer.com to be very reasonable. For about $70 you can get a contract that is prepared by attorneys skilled in IT plus a free consultation. Additionally, there are at least four other documents which should be referenced to in the Contract and are critical to CYA, and good-faith: 1. List of Customer Deliverables (Equipment, Software, Documents, etc) to be Delivered to the Customer. 2. List of Vendor Deliverables (Equipment, Software, Documents, etc) to be Delivered to the Vendor/Contractor. 3. Requirements Specification (Concise statements of what the Customer expects in including functional requirements and processing specification) 4. Functional Specification (Narrative describing how each requirement will be satisfied and within what performance limits) Bottom line… full disclosure, mutual acceptance and good-faith performance. - - **************************************************** Bernie Chief Technology Architect Chief Security Officer cta@...in.net Euclidean Systems, Inc. ******************************************************* // "There is no expedient to which a man will not go // to avoid the pure labor of honest thinking." // Honest thought, the real business capital. // Observe> Think> Plan> Think> Do> Think> *******************************************************
Powered by blists - more mailing lists