HP3000-L Archives

March 1999, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Stigers, Greg [And]" <[log in to unmask]>
Reply To:
Stigers, Greg [And]
Date:
Mon, 8 Mar 1999 17:35:41 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (99 lines)
X-no-Archive:yes
Since I have his permission, here goes.

I want to reply to something that Michael says below, and then to Joseph
Rosenblatt's comments. The idea of relative security was discussed not that
long ago, that you secure a system in keeping other constraints, such as an
assumption of how much trouble someone will go to obtain unauthorized
access. This can even be applied to a single aspect of security, such as the
requiring non-alpha characters in the password, so that a brute force attack
is not worth trying. And the tendency to underestimate how careless one's
users get with their id and passwords has been well attested to. And, I do
have to wonder if auditors, having been fed what they like to eat,
necessarily look for what is new to them, what they might have missed or
misunderstood. Does showing an auditor mainframe-style security on a
non-mainframe system sate their appetite?

But for a system that can reasonably be accessed from outside, from the
Internet or by modem or even by network connection (I tend to think in terms
of systems being compromised from connected systems), there is no telling
how determined someone might be to access the system and do damage, just
because it's there. Perhaps securing one's system to enough to make it too
much work to access will encourage said hacker to move along to find easier
prey. Perhaps not. I only know one individual who obtained unauthorized
access to a system, and that was in college, and he merely used the
illicitly obtained time to learn about the system and to play with the
assigned programming language beyond the scope of the course assignments.
That hardly seems like an instructive case.

As for Joseph Rosenblatt's charge, to take the initiative, while I am
inclined to agree with the sentiment, it is not always possible. Some of us
update our resume at about this time. But when moving on is not immediately
practical, one can and perhaps must do other things. But that becomes
another thread... The relevant question for this thread is how to satisfy a
mainframe mindset to show that MPE security (and any third-party apps)
satisfy the underlying concept, and what are those concepts, anyway?

-----Original Message-----
Geez, make a public commitment to do the paper?

I'm really interested in the topic, but I'm just not sure when I'll have
time
to do it.  You might be right, though -- I could post an outline of sorts
and
look for suggestions...

You're free to quote any of the private email I've sent you on HP3000-L, and

to stir up agitation for me to "put up or shut up" and write the paper.
I'll
even admit that it might get me to do it sooner.  The best part is, I think
both Lee and Jerry might contribute quite valuable criticism.

Thanks for writing!  I've answered email from a couple of other people on
the
subject, also; I'm starting to believe there is more interest than I first
thought (I actually thought it was just Lee and I debating, and that we were

boring everyone else).

I'd hate to try and defend the proposition "MPE can be adequately secured
with no third-party software", though.  On the other hand, I wouldn't want
to
defend that proposition "MPE (or any system) can be adequately secured at
all".  I don't think security falls along a linear spectrum, where you can
say one system (or OS, or product) is more secure than another.  It depends
on what you are trying to protect, and what you are trying to protect it
from, and what the cost of protection is vs. the potential loss, and what
the
probability of loss is, and etc.

A large, complex system can be less (sometimes MUCH less) secure than a
simple one.  And it can be more secure.  Jerry's "granularity of control"
might excite auditors, but (like many of the things DP auditors check) it
frequently has very little to do with actually protecting data.

---
Michael D. Hensley       | mailto:[log in to unmask]
Allegro Consultants Inc. | Visit scenic http://www.allegro.com
408/252-2330             | "Support Bill of Rights Enforcement"

> It is my understanding of netiquette that it would be more appropriate for
> you to go back on list with this, blaming me for suggesting it, than for
> me to drag you back into an on-list discussion. While I am tossing pennies
> by the pair, I think that a draft of said paper, even a very rough off the
> top of one's head outline, would be a good way to get the ball rolling.
> And, I would welcome a change of subject line... there, I did it!

---
Darn, I was hoping no one would ask that!

Seriously, I think it's a good idea, and I'm adding it to my list of papers
I'd like to write.  It would be an excellent candidate for HP3000-L
feedback.

> Have you a write up on how to adequately secure an MPE system without a
> third-party package? My first 3000 shop had SECURITY / 3000, and literally
> did almost nothing with it. And I have stated my opinion before that it is
> good to know what one can do with only the software that comes on the box.

ATOM RSS1 RSS2