Re: Business / Functional Ownership of non business / end user applications

[Jack Suess <jack () UMBC EDU>]

What we are doing on our campus (UMBC)  is looking at applications and determining what level of assurance (or the 
amount of risk is associated with ) the application. For UMBC, this could be level 0 through level 3 (higher is more 
risk, 3=PCI or HIPPA).  Based on the application level of assurance this dictates a set of security procedures we 
follow (e.g. firewall rules, vpn requirement, patch management reporting, etc.)

Where this relates to users is that we  also associate an account with a level of assurance -- we also use level 0 
through 3. Based on assurance level you have different requirements for your account in terms of password rules, etc. 

What we allow a functional group to do is tell us what users of that system should be at which level. HR can give us a 
list of people associated with payroll and tell us what level they need to be. Finance can also do the same. Thus if 
you can approve payroll or pay bills you get set to level 2. If you are a senior administrator or systems administrator 
you get level 3. If your only access is self-service you might be level 1. 

What the single signon does is provide a consistent interface to enforce this myriad set of rules. We use the NIST 
800-63 rules for user accounts to manage password requirements. For example, at our campus level 2 users can not use 
the automated password reset feature but level 1 can.

This gives functional users some control over the security of their system but does not allow them to set arbitrary 
requirements. Level 2 in HR is level 2 in Finance is level 2 in the student system. We actually think this is a plus 
because it allows us to ultimately raise the requirements on a level and consistently enforce this across all systems. 

Without having a single-signon designed to enforce our rules we couldn't do this.

We wrote our own single sign-on back in 2000, which wecalled webauth. It turns out it functions very similar to CAS but 
I can't verify this would work in CAS, though I would be surprised if you can't.

jack suess



On May 12, 2011, at 5:27 PM, Radford, Jennifer wrote:

> Hi all,
>  
> I would let to get a sense of what the norm is out there for ownership of applications that are not directly connect 
> to the end users.  For example, from a best practice perspective, the Payroll application would be owned by the 
> department head for payroll. This owner would be accountable for ensuring their data is secure by communicating 
> required policies to IT so they can set up security configurations etc.  However, my challenge is around applications 
> such as single sign on apps that are pervasive in nature and campus wide – whilst they may have an IT custodian, 
> there may not be a ‘functional / business’ owner assigned to ensure password policies etc as set in line with what 
> senior management requires.
>  
> Any thoughts?
>  
> Cheers,
>  
> Jenny
>  
> Jennifer Radford, Senior IT Audit Manager
> Internal Audit, UBC
> 6000 Iona Drive, Vancouver, BC Canada V6T 1L4
> Phone:  604-822-6512
> Fax:  604-822-9027
> E-mail:  Jradford () intaudit ubc ca
> Web:  www.intaudit.ubc.ca
> The information contained in this e-mail message is strictly confidential and intended solely for the use of the 
> designated addressee(s). Any unauthorized viewing, disclosure, copying or distribution of this e-mail is prohibited 
> and may be unlawful. If you have received this e-mail in error, please do not read it, reply to the sender 
> immediately to inform us that you are not the intended recipient, and delete the e-mail from your computer system. 
> Thank you.
>  

Jack Suess            UMBC VP of IT & CIO
jack () umbc edu    1000 Hilltop Circle
410.455.2582     Baltimore Md, 21250
Homepage:      http://bit.ly/fSB5ID
Blog:                 http://bit.ly/felhWd

Attachment: smime.p7s
Description: