[ale] shared research server help

Todor Fassl fassl.tod at gmail.com
Thu Oct 5 11:57:21 EDT 2017


Hmmm... I kind of feel sorry for that student. Most people aren't idiots 
on purpose. That kid's dream might have been crushed. Some of us have a 
talent for making computers work and some of us don't. If you don't have 
the talent, you ought never to persue a career doing exactly that. Even 
that was kind of stupid. But that student wasted a lot of time and money 
persuing a career only to find out he can't cut it. That's sad.

IMO, the customer is always right. The students are the customers. 
Obviously, I'm not saying they ought to be able to ignore security 
regulations or even common sense. It is a good thing they have this 
sense of entitlement because they are entitled. These aren't my 
machines. The students paid for them, not me. Well, the federal  and 
state governments paid a hefty proportion too. As a taxpayer, I paid for 
them too. But the taxpayers provided the funding with the understanding 
they'd be used for educational purposes. They're not mine.

No business says the customer is always right meaning it to be taken 
literally. They say that to remind themselves and their employees that 
customers are not the enemy. I think if you don't tell yourself the 
customer is always right, it is too easy to become bad IT guy.

On 10/05/2017 10:06 AM, Jim Kinney wrote:
> +1!
> 
> I'm the admin. The machines are MINE. I WILL have the authority to do 
> what is needed to fulfill my responsibilities. I have kicked a student 
> off systems before (hyper-extreme case). His code was utter crap and 
> resulted in a reboot EVERY time he ran it (all nodes on the cluster 
> would lock up - he had been given sudo by his advisor - once I took it 
> away his code wouldn't run at all). His advisor whined and complained 
> and I made the case that his idiot student was effectively the turd in 
> the punchbowl for the cluster (I think I actually used those words) and 
> it broke things for everyone else. Advisor got him a workstation to use, 
> it was offline most of the time as he still wrote crap. When he finally 
> got sudo on the workstation (I had to cough it up as the box belonged to 
> the advisor) the idiot ran his code as root. Justice happened swiftly as 
> his garbage trashed the hard drive and deleted his home dir. I don't 
> back up standalone machines like that so his work was gone. good 
> riddance. He (without permission) installed ubuntu, was the admin and 
> proceeded to crash that box daily/hourly until he was finally shown the 
> door for failing to complete a single project assignment.
> 
> Dev make terrible admins. Devs make terrible security officers. Devs 
> need to be throttled by hardware so they learn how to write efficient 
> code. One faculty gets the cheapest old crap machines for new students 
> to run their code on so they are forced to make improvements in 
> performance. It's mostly a pretty good idea.
> 
> On Thu, Oct 5, 2017 at 10:37 AM, Jerald Sheets <questy at gmail.com 
> <mailto:questy at gmail.com>> wrote:
> 
> 
>>     On Oct 5, 2017, at 9:27 AM, Todor Fassl <fassl.tod at gmail.com
>>     <mailto:fassl.tod at gmail.com>> wrote:
>>
>>     This list has really come through for me again just with ideas I
>>     can bounce around. I'll have to tread lightly though. About a year
>>     ago, I configured the machines in our shared labs to log someone
>>     off after 15 minutes of inactivity. Believe it or not, that was
>>     controversial. Not with the faculty but with the students using
>>     the labs. It was an easy win for me but some of the students went
>>     to the faculty with complaints. Wait, you're actually defending
>>     your right to walk away from a workstation in a public place still
>>     logged in? In a way that's not such a bad thing. This is a
>>     university and the students should run the place. But they need a
>>     referee.
>>
> 
>     TL;DR: I disagree.  Follow compliance guidelines. People could go to
>     jail in a governmental (college) setting. The laws are the referee,
>     not us.
> 
> 
> 
>     I respectfully disagree.
> 
>     Let me flex my ego muscle for a moment:  “Jerald Sheets, Lead
>     Security Architect - Infrastructure Hardening - PayPal, Inc” at your
>     service.
> 
> 
>     Any university is bound by common rules and guidelines to adhere to
>     “generally accepted security standards” in regards to systems
>     connected to the university infrastructure for the purposes of
>     satisfying protection of PII of students, faculty, and staff.  This
>     is also governed by FRPA and can include jail time under the right
>     circumstances…  Just saying.
> 
>     Regardless of physical, network, and other similar security controls
>     in place, host security demands that TMOUT be on, enabled, and
>     unable to be circumvented.
> 
> 
> 
> 
>     *HIPAA:*
> 
>     A covered entity should activate a password-protected screensaver
>     that automatically prevents unauthorized users from viewing or
>     accessing electronic protected health information from unattended
>     electronic information system devices.
> 
>     *SOX:*
> 
>     User session timeout is defined and in place for authorized users
>     Audit and review user privil
> 
>     *ITIL:*
> 
>     ISO/IEC 27002
>     11.5.5 Session time-out
> 
>     *PCI:*
> 
>     8.5.15 Idle Session Timeout threshold
> 
>       * Disconnect Idle session is less than or equal to 15 minutes
> 
> 
> 
> 
>     These are the reasonings I use with CISOs, CIOs and CEOs to explain
>     to them that just because Devs are yelling about various security
>     controls does not mean they get to have what they want.
> 
>     “You could go to jail over this one” has been uttered more than once
>     by me, and I count it a great responsibility on my part as a
>     Security guy first and a Systems guy second to ensure that the law
>     and various compliance guidelines are followed.
> 
>     If I have people continuing to demand non-compliance, I work up a
>     business case for them to sign their name to “when the auditors come
>     around on this, they’ll want to know who’s responsible and who
>     should be prosecuted in the event of data loss or breach”.  That
>     usually gets their attention and gets them to think twice about
>     these things.
> 
>     The balance is ALWAYS security versus usability, and the security
>     guidelines we are both legally and honor-bound to follow are the
>     “referee” here.  You aren’t.  I implement what’s given to me within
>     the confines of the law, and I do not step outside of it.  No
>     student, teacher, full or associate professor, department chair has
>     the authority to overrule these guidelines.
> 
>     The board or president of your university does, and they are
>     ultimately responsible (as any CEO would be) for what goes on both
>     physically and virtually on their campus.
> 
> 
>     —j
> 
> 
> 
>     _______________________________________________
>     Ale mailing list
>     Ale at ale.org <mailto:Ale at ale.org>
>     http://mail.ale.org/mailman/listinfo/ale
>     <http://mail.ale.org/mailman/listinfo/ale>
>     See JOBS, ANNOUNCE and SCHOOLS lists at
>     http://mail.ale.org/mailman/listinfo
>     <http://mail.ale.org/mailman/listinfo>
> 
> 
> 
> 
> -- 
> -- 
> James P. Kinney III
> ////
> ////Every time you stop a school, you will have to build a jail. What 
> you gain at one end you lose at the other. It's like feeding a dog on 
> his own tail. It won't fatten the dog.
> - Speech 11/23/1900 Mark Twain
> ////
> http://heretothereideas.blogspot.com/
> ////
> 
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
> 

-- 
Todd


More information about the Ale mailing list