Skip to Content.
Sympa Menu

cacert-sysadm - Re: [Cacert-sysadm] Security Manual comments

cacert-sysadm AT lists.cacert.org

Subject: CAcert System Admins discussion list

List archive

Re: [Cacert-sysadm] Security Manual comments


Chronological Thread 
  • From: Daniel Black <daniel AT cacert.org>
  • To: cacert-sysadm AT lists.cacert.org
  • Subject: Re: [Cacert-sysadm] Security Manual comments
  • Date: Fri, 20 Jun 2008 07:22:51 +1000
  • List-archive: <http://lists.cacert.org/pipermail/cacert-sysadm>
  • List-id: CAcert System Admins discussion list <cacert-sysadm.lists.cacert.org>
  • Organization: CACert

On Fri, 20 Jun 2008 05:06:16 am IanG wrote:
> Hi Pat,
>
> as we don't have a security list, I'll post some comments
> here, below.

Good idea.

> From 1.2 --> 2.2 inclusive. 
>
>
>
> For others, the evolving SecurityManual is here:
>
> http://wiki.cacert.org/wiki/SecurityManual
>
> under editorial direction by Pat.  She would probably
> appreciate any suggestions.
>
> ==========
> 1.2 Physical assets.
>
> Where is the inventory to be located?  Currently, future?

I started https://wiki.cacert.org/wiki/SystemAdministration/Systems/Email as ;
an example. Is a system by system location sufficient?

> Who can inspect this?
> Is it likely to be a 
> controlled-distro document?  Or can we open it up for the
> world to see what kit we have?

For those that know the facilites is this being public going to incur 
additional risks.

> (If we agree that it is a controlled-distribution document,
> then we could possibly create an access mechanism via the wiki?)

I agree.

> ==========
> 1.2.3.2 Destruction
> I'm less concerned by the method of destruction than by who
> is doing it and who witnesses the results.  Can we add
> something like:
>
> Record of secure erasure should describe:  who carried out
> the procedure, who witnessed, method of final disposal.  It
> should be signed by the person concerned.
>

good.

note - probably should add a section about maintaince by vendors/contractors 
as far as sanitisation/supervision.

> ==========
> 2.1.1 Infrastructure
> Diagrams of physical / logical.  Again, I'm concerned that
> they be *available for scrutiny* because if not then they
> will be lost, if not in reality, in effect.
>
> Can we decide where the diagrams are held, and in what form?
>   I'm assuming digital, which of course then leads to a
> discussion of what tools...

i've got some in svg which is ok. I just use inkscape currently.

> ==========
> 2.1.2.1/2 Ingress and Outgress
> I see this blocks idle ports.  OK.
>
> What it does not say is whether access is blocked by IP#s.

true. probably should - I've incuded this in the Email system wiki page.
I need to do outgress usages too.

> Currently, Philipp has it set up to block SSH access unless
> in a white-list.

it lowered our risk profile with the debian ssh thing went public.

> This was a serious issue;

I'm happy if this is limited provided the admins have access via a static IP. 
My relaying off a box Philipp controls isn't ideal but it works.

> if there is a  
> decision that this is policy, then we should also add that
> part to that section.
>
> My understanding is at this stage Teus has accepted it as
> policy, so it should go in.

Something like: "if possible tcp/ip services services should be limited to a 
location where they are used."

>
> Or is this an issue for 2.4 Access Control?

for ssh i'd say it is. thats 1/2 why i did that rough statement in tcp/ip 
services terms.

> ==========
> 2.1.3. Intrusion detection
> Who is the appropriate person?  It could be "systems
> administrator designated for that role" or "systems
> administraion team leader"

i'm more in favour of these two.

> I'm not so fussed who it is, I would just make my life
> easier if I can see a name or role, then I can ask that
> person some audit questions.
>
>
>
> ==========
> 2.2.2 Patching
>
> You have kicked the central discussion over to the CCS
> there, which is fine.  There are some changes there, which
> now says:
>
>
> http://wiki.cacert.org/wiki/PolicyDrafts/ConfigurationControlSpecification
>   -------------
> The Systems Administration Officer (SAO) is responsible for
> implementing changes to any kind of software.

notice this has some good scoping that the SM doesn't.

> The SAO maintains a log to record all changes and reports to
> software. All software installations and updates are logged.
>
> Software changes should be checked and approved by a second
> system administrator. If another administrator is not
> available, the check is generally deferred.
>
> Patches. The SAO watches and tracks the newsfeed of patches
> from distributors of software. CAcert uses the stable branch
> of any distribution,

approval process for non-stable packages defining business case and the risks 
incurred?

> and applies patches when deemed 
> necessary. The SAO authorises the patch and notifies M-SC of
> the intention.

intention or result?
>
> New Software. New software, configurations or ports that are
> not encapsulated in vendor patches are to be authorised by
> M-SC on request by SAO.
>
> List. Changes to the above list of controlled software are
> authorised by M-SC on submission from SAO.


-- 
Daniel Black 
(daniel AT cacert.org)
Email Adminstrator

Attachment: signature.asc
Description: This is a digitally signed message part.




Archive powered by MHonArc 2.6.16.

Top of Page