On 31/03/17 23:04, jdow wrote:
> On 2017-03-31 13:44, David Sommerseth wrote:
>> On 31/03/17 13:40, James M. Pulver wrote:
>>> Shouldn't we all take a step back here and ask why your IT support isn't
>>> providing the resources you need to run the experiment?
>>
>> This is absolutely important to consider for the person going to do such
>> a project.  But that shouldn't stop us on this ML to try to provide some
>> solutions which can work.
>>
>> If this person doesn't use these solutions, others in completely
>> different needs may use this information for their challenges.
>>
>> Mailing lists are a good place to "think aloud" and get input and ideas,
>> to share knowledge and learn new things.
>>
>> I for one will not stop sharing my knowledge when I feel I have
>> something valuable to share.  Whether people use or find my input
>> valuable and useful or not is secondary to the sharing itself.  Because
>> we all grow when we share.
> 
> If the fellow cannot figure out how to add the second card and make it
> work (he had to ask here, after all) then he is utterly in over his head
> for security. I read the SANS Diary following their discussions as an
> utter amateur. It gives me an idea of what is going around so I can work
> to avoid it. This question is one of the chief IT nightmare scenarios.
> It opens a side door into a secure network. Side doors are generally
> very easy to penetrate. Once that happens the entire network and all the
> site's data storage are up for grabs or are at least one layer of the
> onion closer to being penetrated. 

All very true.  But if the information doesn't come from here, it comes
from another place.  Perhaps even more hackier and with even worse
security around it.

There is however only one realistic way to avoid such scenarios though.
Corporate policies, where people get reminded about them on a regular
basis over time.  I know some places they did minor updates (could just
be simple grammar fixes) so they could send out a mail to all employees
about the updated policy (even though I found _that_ approach a bit
annoying).

> I know that if I was "in charge"
> anybody who did this would be fired upon it's discovery, not "let go" or
> "laid off" but really "fired for cause". Security compromises can eat
> his salary up each minute for hours on end in costs, legal fees,
> restitution, and so forth.

That is exactly what the employee contract needs to state, with a
reference to the corporate policy defining what you can and cannot do.

> The correct "hack" here is to walk up the management chain properly.
> Sell your case to your boss. Have your  boss sell it to his boss.
> Lather, rinse, repeat until the "boss" is at a level to communicate with
> the IT boss. And be prepared to compromise. Also remember that YOUR
> convenience is a very weak selling point in the face of security; but,
> not being able to perform your assigned duties, is. It can be very hard
> to explain in many cases. But solutions need to be worked out. One such
> case is a department which makes dramatic presentations using
> computerized hardware in a secure workplace with an aggressive IT
> department. 

Yes, in an ideal world this would be perfect.  And it would probably
work wonderfully well too!

I've been working with IT professionally since late 90s, worked in both
small start-ups and large enterprises, and everything in between, over
all these years.  Most of the times as full-time employee other times as
a hired consultant.  I have been through several rounds of PCI-DSS and
Visa/MasterCard security audits and certifications, been responsible for
the network security several more places.

My experience is that you need to be very lucky with your organisation
to actually find that each of these "leadership levels" fully understand
and be interested in what you are saying as a requestor.

I have experienced leaders saying "NO!" by default by just hearing the
word "network", without further chances to discuss it.  And I have
experienced my closest leader saying "Go ahead, just do it! I'll ensure
it gets approved!" and then experience the request never got a formal
approval, sometimes it never went further.  And the "fun" detail is that
it doesn't matter what kind of organisation it is, small or large, from
basically no processes to way too slow and long-dragging processes; I've
seen the whole spectre of leaders in all of them.

In my experience, with way too many leaders there is only one primary
question you need to have a good answer to to get an approval:  "What's
in it for me [as the leader]?"   If it can make the leader look good
among his group of fellows, the odds of getting an approval gets
annoyingly higher.  The technical aspect of it?  In reality, way too
often too boring for such leaders.   (I do not claim all leaders are
like that, not at all!  But way too many are).

Which again is why a corporate policy is a good tool.  There it should
be described what is allowed and what is explicitly prohibited.  And
which chain of command to follow to get such requests properly handled.
Those companies having that, have in my experience less bureaucratic
processes to achieve what you need to do you job.  And in most cases,
these processes are led outside all the middle-level managers.

Now, if an employee deliberately ignores the corporate policy, you have
enough to do drastic actions towards that employee.  Otherwise, without
that things tend to get a bit more complicated - as then there's each
level of management who wants to agree or disagree with what you did was
right or wrong.

But when someone comes here and asks for an advice, shares an idea ...
we shouldn't really care about "Do you follow the corporate policy in
your workplace?".  That is in reality irrelevant in a technical
discussion among technical users.  We have no obligation to babysit
anyone.  We can mention this needs to be allowed when it is a really
special situation, but ultimately following a corporate policy is the
employees task - not anyone else.

Another last detail ... if a company trusts users to have root/admin
access on their computer ... that is usually a way to indicate trust.
"We trust you won't do anything stupid with our network and equipment".


-- 
mvh.

David Sommerseth