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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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