(long) Re: DragonFly Security Officer and Security Team
On Thu, Nov 18, 2004 at 10:43:16AM -0800, Matthew Dillon wrote:
> I've been ignoring this thread because, well, because I have over
> 200 emails backed up that I have yet to take action on and I'm
> getting way way behind!
I think it's normal in this "industry" ...my action list is not that
big, but it's much bigger than I'd like at this moment. :-\ (I'd really
like to pickup where I left off with C and doc...)
> Just tell me what email addresses to add to the security alias
> and I'll do it... as long as its people who have already been
> associated with the project for some time (which is to say, most
> of the people who have been discussing it, eh?).
>
> I suppose we can create a closed list for internal security issues
> discussions as well, but lets just start with an alias for now.
>
I don't know how many emails or people we are talking about, but would
delivering "security" to all the commiters cause any problems?
For deploying in regulated industry, there is something else relevant
than patching security issues: qualification. Setting up regulated
systems requires defining objectives and documenting how they are met.
Admins and security people naturally over interpret qualification, it
means setting attainable goals and documenting the process of reaching
them; qualification is not the _act_of_approaching_ some unattainable
level of quality (eg 100% security, though that could be an ultimate
direction of the process).
When the auditor is as big a threat as an attacker, sound process (and
adherence) is as important as, well, encryption. Catering to regulators
is not about demonstrating "best effort" but process adherence.
DFLY is not regulated, and every change requires "outside of the box"
methods, and continuous revising of objectives; so, what is the point
of raising all this here? Any "hooks" into the OS QA process will go
a long way toward satisfying regulation requirements in a production
environment.
For example to satisfy this
We suggest that your decision to validate computerized systems,
and the extent of the validation, take into account the impact
the systems have on your ability to meet predicate rule
requirements. You should also consider the impact those systems
might have on the accuracy, reliability, integrity, availability,
and authenticity of required records and signatures. Even if there
is no predicate rule requirement to validate a system, in some
instances it may still be important to validate the system.
with this
뜠determination that persons who develop, maintain, or use
electronic systems have the education, training, and experience to
perform their assigned tasks
뜠establishment of and adherence to written policies that hold
individuals accountable for actions initiated under their electronic
signatures
by referencing the policy by which (third party, DFLY) commiters are
elected, would go a long way.
On the software level, defining the requirements a package satisfies and
defining the spec it (and its installation!) supports will make the OS a
1,000 times easier to deploy in a regulated environment. For example see
the qa paragraph from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282306
All in all, the apache.postinst file seems very delicately
balanced to support (and only support) a complex set of
requirements. Is the supported spec defined anywhere? Such a
spec would go a long way on qa.debian.org.
(It would also help a lot at sites who want to use an OS, but maybe
not _exactly_ the way it is supported.)
Most admins know, a secure site is not vulnerable to a single breach or
point of failure; likewise, every spec that validates the integrity of a
defined process of system creation, makes it more credible in the eyes
of an auditor.
DFLY doesn't need to be certified regulation compliant, but the more
definitions of quality assurance (process not product!), the more
streamlined the regulated deployment.
As you may have guessed, I have direct interest in regulated OS
deployment. I will do everything I can to develop DFLY qualifications,
and start by looking into what exactly a QA prime directive could/should
be, from which supporting definitions can develop. Any ideas?
// George
--
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@galis.org
討論串 (同標題文章)
完整討論串 (本文為第 1 之 4 篇)：