On 2017-03-31 15:29, David Sommerseth wrote:
> 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".

David, if the company has a mission it must do "stop work" memos have a talent 
for rocketing up the management bloat or pyramid, whichever exists, to people 
who can solve it or it is time for the fellow to abandon ship because the 
company will fail, fairly soon. But, the memo that does this must be well 
written, factual, and address why alternative approaches will not work. It's 
very hard to write the effective memo. That's not an excuse for whining and 
going around IT's back. Would YOU like to risk being the reason your company is 
facing 7 to 8 figures of legal fees, restitution, identity protection, and other 
problems? You you like to be sitting there fat dumb and happy when IT, your 
boss, and company security come to your cubical or office to frog march you out 
in extreme disgrace? Do you think you are so lucky you're little router will not 
be discovered? Maybe that doesn't bother you. It bothers me. I have a clean 
record in this regard and a lapsed secret clearance for the work I was doing. (I 
do civilian stuff now, when I get moved to do it. At 73, well, if it ain't fun I 
don't do it. {^_-}) I also am a bit paranoid, perhaps. But, in a very practical 
sense "They" are out to get you. Even mom and pop book stores get hacked. If 
there is money in the hack, it gets done.

If you can do the job another way that is not convenient but is supported within 
the company, then it's time to "quitcherbitchen" and get to work.

It's his job, his reputation, and his call what he does. I am simply offering 
some experience of a lifetime of finding ways to cooperate with IT and still get 
the job done. It CAN be done. Just make the business case for it.

{^_^}