Main Nav

Hello Colleagues,

 

At your University, what department or function is responsible for the overall administration of the PCI DSS program i.e. administrator of policy(PCI requirement 12), etc.?

 

I would really appreciate your responses.

 

Carlos

 

Carlos S. Lobato, CISA, CIA

IT Compliance Officer

 

New Mexico State University

Information and Communication Technologies

MSC 3AT PO Box 30001

Las Cruces, NM  88003

 

Phone (575) 646-5902

Fax (575) 646-5278

Comments

Same here. It's based on the banking relationship, so the Treasurer's office, but the ISO does the "hand-holding" for the technical controls an risk assessment.

Good luck,

Dan

On Mar 12, 2013 7:49 PM, "Harry Hoffman" <hhoffman@ip-solutions.net> wrote:
Treasure's office, both this job and the last.

Cheers,
Harry

On 03/12/2013 06:11 PM, Carlos Lobato wrote:
> Hello Colleagues,
>
>
>
> At your University, what department or function is responsible for the overall administration of the PCI DSS program i.e. administrator of policy(PCI requirement 12), etc.?
>
>
>
> I would really appreciate your responses.
>
>
>
> Carlos
>
>
>
> Carlos S. Lobato, CISA, CIA
>
> IT Compliance Officer
>
>
>
> New Mexico State University
>
> Information and Communication Technologies
>
> MSC 3AT PO Box 30001
>
> Las Cruces, NM  88003
>
>
>
> Phone (575) 646-5902
>
> Fax (575) 646-5278
>
I didn't know that everything posted on this listserv is made public on the Internet. It's like we're giving our enemy all of the information that they need to circumvent the systems that are discussed here. Not a good idea. Zachery S. Mitcham, MSA On Mar 12, 2013, at 22:05, "Cathy Hubbs" > wrote: Ditto for American University. Happy to discuss offline as you move forward with your program. Cathy Hubbs
http://textfiles.vistech.net/hacking/hackfaq.txt Zachery S. Mitcham, MSA | Information Technology Security Officer| Information Technology Systems (ITS)| 910 962 3047|mitchamz@uncw.edu | http://www.uncw.edu/itsd/about/ITS.html |UNC Wilmington |  601 South College Road | Wilmington, NC  28403-5616 "Security is Everyone's Business"   AskTAC for self-service solutions and immediate assistance! (https://asktac.uncw.edu/) NOTICE: Emails sent and received in the course of university business are subject to the North Carolina Public Records Act (N.C.G.S. §132-1 et seq.) and may be released to the public unless an exception applies. -----Original Message----- From: Harry Hoffman [mailto:hhoffman@ip-solutions.net] Sent: Wednesday, March 13, 2013 8:09 AM To: The EDUCAUSE Security Constituent Group Listserv Cc: Mitcham, Zachery S. Subject: Re: [SECURITY] Administration of PCD DSS Program I don't, regularly, see things posted here that I'd consider mission critical information (famous last words). I certainly wouldn't post configs to any public (and archived) list. If you're looking for a community that specifically targets those that are responsible for the security of your educational organization you should look to join REN-ISAC [1]. It's a private/vetted community that might be worthwhile to join. Cheers, Harry [1] http://www.ren-isac.net/ On 03/13/2013 07:25 AM, Mitcham, Zachery S. wrote: > I didn't know that everything posted on this listserv is made public on the Internet. It's like we're giving our enemy all of the information that they need to circumvent the systems that are discussed here. Not a good idea. > > > > Zachery S. Mitcham, MSA > > > On Mar 12, 2013, at 22:05, "Cathy Hubbs" > wrote: > > Ditto for American University. > > Happy to discuss offline as you move forward with your program. > > Cathy Hubbs > > >
Actually there are two different schools of thought here. They address different issues.
  1. Your security should not depend on obscurity.
  2. Defense in depth, you shouldn't give the adversary any advantage.
They are not necessarily in conflict. [1] is primarily targeted at developers. As developers your code's security shouldn't depend on the source remaining secret. Because quite frankly, the bad guys will get a copy and if you hide "secrets" in your code, your code probably isn't that secure in the first place.

So when developing systems, [1] should be your guide.

[2] is more often associated with operational practices. Here the attack surface isn't always technical, it is human oriented. I.e., the attacks here are social engineering related. Letting the attacker know the chain of command only makes it that much easier to launch a social engineering attack. Ideally the principals of [1] *should* apply here, but thousands of years of human experience demonstrates that it doesn't always work.

So in summary you should do [1] when developing code (and procedures) but do [2] when it comes to operational concerns.

-Jeff


http://tech.mit.edu/V132/N62/hack.html

 

Zachery S. Mitcham, MSA | Information Technology Security Officer| Information Technology Systems (ITS)|

910 962 3047|mitchamz@uncw.eduhttp://www.uncw.edu/itsd/about/ITS.html |UNC Wilmington | 

601 South College Road | Wilmington, NC  28403-5616

"Security is Everyone's Business"

  AskTAC for self-service solutions and immediate assistance! (https://asktac.uncw.edu/)

 

NOTICE: Emails sent and received in the course of university business are subject to the North Carolina Public Records Act (N.C.G.S. §132-1 et seq.) and may be released to the public unless an exception applies.

 

 

 

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey Schiller
Sent: Wednesday, March 13, 2013 9:11 AM
To: SECURITY@LISTSERV.EDUCAUSE.EDU
Subject: Re: [SECURITY] Administration of PCD DSS Program

 

Actually there are two different schools of thought here. They address different issues.

  1. Your security should not depend on obscurity.
  2. Defense in depth, you shouldn't give the adversary any advantage.

They are not necessarily in conflict. [1] is primarily targeted at developers. As developers your code's security shouldn't depend on the source remaining secret. Because quite frankly, the bad guys will get a copy and if you hide "secrets" in your code, your code probably isn't that secure in the first place.

 

So when developing systems, [1] should be your guide.

 

[2] is more often associated with operational practices. Here the attack surface isn't always technical, it is human oriented. I.e., the attacks here are social engineering related. Letting the attacker know the chain of command only makes it that much easier to launch a social engineering attack. Ideally the principals of [1] *should* apply here, but thousands of years of human experience demonstrates that it doesn't always work.

 

So in summary you should do [1] when developing code (and procedures) but do [2] when it comes to operational concerns.

 

-Jeff

 

I didn't know that everything posted on this listserv is made public on the Internet. It's like we're giving our enemy all of the information that they need to circumvent the systems that are discussed here. Not a good idea. Zachery S. Mitcham, MSA On Mar 12, 2013, at 22:05, "Cathy Hubbs" > wrote: Ditto for American University. Happy to discuss offline as you move forward with your program. Cathy Hubbs
Message from hhoffman@ip-solutions.net

I don't, regularly, see things posted here that I'd consider mission critical information (famous last words). I certainly wouldn't post configs to any public (and archived) list. If you're looking for a community that specifically targets those that are responsible for the security of your educational organization you should look to join REN-ISAC [1]. It's a private/vetted community that might be worthwhile to join. Cheers, Harry [1] http://www.ren-isac.net/ On 03/13/2013 07:25 AM, Mitcham, Zachery S. wrote: > I didn't know that everything posted on this listserv is made public on the Internet. It's like we're giving our enemy all of the information that they need to circumvent the systems that are discussed here. Not a good idea. > > > > Zachery S. Mitcham, MSA > > > On Mar 12, 2013, at 22:05, "Cathy Hubbs" > wrote: > > Ditto for American University. > > Happy to discuss offline as you move forward with your program. > > Cathy Hubbs > > >
If your systems can be circumvented from information discussed on a public list you have bigger problems to worry about. If your systems are really secure, you should have no problems discussing the measures you took to secure them openly and in the public. Public discussion of good security practices is the best way promote good security (assuming there is such a thing). Just my 2 cents. ~Daniel -- Daniel Wozniak Orvant, Inc. Email/XMPP : dan@orvant.com Phone : +01 480 553 8939 ext 103
I can tell by your coy comment that you are a novice. Intel can be gathered from the things that you discuss that you feel are crumbs and insignificant records of public knowledge. If you are telling someone that you are using the Symantec enterprise suite for A/V eradication they could develop their APT around this intel in such a way as to prevent your infected systems from getting to the host site that could save them. My 2 cents. Zachery S. Mitcham, MSA On Mar 13, 2013, at 8:13, "Daniel Wozniak" wrote: > If your systems can be circumvented from information discussed on a > public list you have bigger problems to worry about. If your systems are > really secure, you should have no problems discussing the measures you > took to secure them openly and in the public. Public discussion of good > security practices is the best way promote good security (assuming there > is such a thing). Just my 2 cents. > > ~Daniel > > > -- > Daniel Wozniak > Orvant, Inc. > Email/XMPP : dan@orvant.com > Phone : +01 480 553 8939 ext 103 > > > >
http://textfiles.vistech.net/hacking/hackfaq.txt Zachery S. Mitcham, MSA | Information Technology Security Officer| Information Technology Systems (ITS)| 910 962 3047|mitchamz@uncw.edu | http://www.uncw.edu/itsd/about/ITS.html |UNC Wilmington |  601 South College Road | Wilmington, NC  28403-5616 "Security is Everyone's Business"   AskTAC for self-service solutions and immediate assistance! (https://asktac.uncw.edu/) NOTICE: Emails sent and received in the course of university business are subject to the North Carolina Public Records Act (N.C.G.S. §132-1 et seq.) and may be released to the public unless an exception applies. -----Original Message----- From: Harry Hoffman [mailto:hhoffman@ip-solutions.net] Sent: Wednesday, March 13, 2013 8:09 AM To: The EDUCAUSE Security Constituent Group Listserv Cc: Mitcham, Zachery S. Subject: Re: [SECURITY] Administration of PCD DSS Program I don't, regularly, see things posted here that I'd consider mission critical information (famous last words). I certainly wouldn't post configs to any public (and archived) list. If you're looking for a community that specifically targets those that are responsible for the security of your educational organization you should look to join REN-ISAC [1]. It's a private/vetted community that might be worthwhile to join. Cheers, Harry [1] http://www.ren-isac.net/ On 03/13/2013 07:25 AM, Mitcham, Zachery S. wrote: > I didn't know that everything posted on this listserv is made public on the Internet. It's like we're giving our enemy all of the information that they need to circumvent the systems that are discussed here. Not a good idea. > > > > Zachery S. Mitcham, MSA > > > On Mar 12, 2013, at 22:05, "Cathy Hubbs" > wrote: > > Ditto for American University. > > Happy to discuss offline as you move forward with your program. > > Cathy Hubbs > > >
Actually there are two different schools of thought here. They address different issues.
  1. Your security should not depend on obscurity.
  2. Defense in depth, you shouldn't give the adversary any advantage.
They are not necessarily in conflict. [1] is primarily targeted at developers. As developers your code's security shouldn't depend on the source remaining secret. Because quite frankly, the bad guys will get a copy and if you hide "secrets" in your code, your code probably isn't that secure in the first place.

So when developing systems, [1] should be your guide.

[2] is more often associated with operational practices. Here the attack surface isn't always technical, it is human oriented. I.e., the attacks here are social engineering related. Letting the attacker know the chain of command only makes it that much easier to launch a social engineering attack. Ideally the principals of [1] *should* apply here, but thousands of years of human experience demonstrates that it doesn't always work.

So in summary you should do [1] when developing code (and procedures) but do [2] when it comes to operational concerns.

-Jeff


http://tech.mit.edu/V132/N62/hack.html

 

Zachery S. Mitcham, MSA | Information Technology Security Officer| Information Technology Systems (ITS)|

910 962 3047|mitchamz@uncw.eduhttp://www.uncw.edu/itsd/about/ITS.html |UNC Wilmington | 

601 South College Road | Wilmington, NC  28403-5616

"Security is Everyone's Business"

  AskTAC for self-service solutions and immediate assistance! (https://asktac.uncw.edu/)

 

NOTICE: Emails sent and received in the course of university business are subject to the North Carolina Public Records Act (N.C.G.S. §132-1 et seq.) and may be released to the public unless an exception applies.

 

 

 

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey Schiller
Sent: Wednesday, March 13, 2013 9:11 AM
To: SECURITY@LISTSERV.EDUCAUSE.EDU
Subject: Re: [SECURITY] Administration of PCD DSS Program

 

Actually there are two different schools of thought here. They address different issues.

  1. Your security should not depend on obscurity.
  2. Defense in depth, you shouldn't give the adversary any advantage.

They are not necessarily in conflict. [1] is primarily targeted at developers. As developers your code's security shouldn't depend on the source remaining secret. Because quite frankly, the bad guys will get a copy and if you hide "secrets" in your code, your code probably isn't that secure in the first place.

 

So when developing systems, [1] should be your guide.

 

[2] is more often associated with operational practices. Here the attack surface isn't always technical, it is human oriented. I.e., the attacks here are social engineering related. Letting the attacker know the chain of command only makes it that much easier to launch a social engineering attack. Ideally the principals of [1] *should* apply here, but thousands of years of human experience demonstrates that it doesn't always work.

 

So in summary you should do [1] when developing code (and procedures) but do [2] when it comes to operational concerns.

 

-Jeff

 

For NDSU,  Customer Accounts Department (under Office of Finance and Administration) has oversight with technical assistance from the IT security office.

 

Theresa Semmens, CISA

NDSU Chief IT Security Officer

Office: 210D IACC

Mail: NDSU Dept 4500

PO Box 6050

Fargo, ND 58108-6050

P: 701-231-5870

F: 701-231-8541

E: Theresa.Semmens@ndsu.edu

www.ndsu.edu/its/security

 

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY@LISTSERV.EDUCAUSE.EDU] On Behalf Of Cathy Hubbs
Sent: Tuesday, March 12, 2013 9:05 PM
To: SECURITY@LISTSERV.EDUCAUSE.EDU
Subject: Re: [SECURITY] Administration of PCD DSS Program

 

Ditto for American University. 

 

Happy to discuss offline as you move forward with your program. 

Cathy Hubbs

 


Well. I suspect this was the result of the password database breach at EDUCAUSE.

-Jeff


Message from hhoffman@ip-solutions.net

I don't understand what you are trying to say with these URLs. Is it that somehow these hacks happened as a result of open discussions? Or are you just saying that hacking is possible? Or something else entirely? Cheers, Harry On 03/13/2013 09:17 AM, Mitcham, Zachery S. wrote: > http://tech.mit.edu/V132/N62/hack.html > > [cid:image001.gif@01CE1FCB.9B8A0920] > Zachery S. Mitcham, MSA | Information Technology Security Officer| Information Technology Systems (ITS)| > 910 962 3047|mitchamz@uncw.edu | http://www.uncw.edu/itsd/about/ITS.html |UNC Wilmington | > 601 South College Road | Wilmington, NC 28403-5616 > "Security is Everyone's Business" > [cid:image002.png@01CE1FCB.9B8A0920] AskTAC for self-service solutions and immediate assistance! (https://asktac.uncw.edu/) > > NOTICE: Emails sent and received in the course of university business are subject to the North Carolina Public Records Act (N.C.G.S. §132-1 et seq.) and may be released to the public unless an exception applies. > > > > From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey Schiller > Sent: Wednesday, March 13, 2013 9:11 AM > To: SECURITY@LISTSERV.EDUCAUSE.EDU > Subject: Re: [SECURITY] Administration of PCD DSS Program > > Actually there are two different schools of thought here. They address different issues. > > 1. Your security should not depend on obscurity. > 2. Defense in depth, you shouldn't give the adversary any advantage. > They are not necessarily in conflict. [1] is primarily targeted at developers. As developers your code's security shouldn't depend on the source remaining secret. Because quite frankly, the bad guys will get a copy and if you hide "secrets" in your code, your code probably isn't that secure in the first place. > > So when developing systems, [1] should be your guide. > > [2] is more often associated with operational practices. Here the attack surface isn't always technical, it is human oriented. I.e., the attacks here are social engineering related. Letting the attacker know the chain of command only makes it that much easier to launch a social engineering attack. Ideally the principals of [1] *should* apply here, but thousands of years of human experience demonstrates that it doesn't always work. > > So in summary you should do [1] when developing code (and procedures) but do [2] when it comes to operational concerns. > > -Jeff > >
I suspect that it is the result of intel gathered over public venues, footprinting, social engineering,etc Loose lips; sink ships Please consider closing this thread to the public or send me information on how I can unsubscribe. Thank you Zachery S. Mitcham, MSA On Mar 13, 2013, at 9:41, "Jeffrey Schiller" > wrote: Well. I suspect this was the result of the password database breach at EDUCAUSE. -Jeff
This is exactly what I'm saying. Excellent interpretation and reading between the lines Zachery S. Mitcham, MSA On Mar 13, 2013, at 9:46, "Harry Hoffman" wrote: > I don't understand what you are trying to say with these URLs. Is it > that somehow these hacks happened as a result of open discussions? > > Or are you just saying that hacking is possible? > > Or something else entirely? > > Cheers, > Harry > > On 03/13/2013 09:17 AM, Mitcham, Zachery S. wrote: >> http://tech.mit.edu/V132/N62/hack.html >> >> [cid:image001.gif@01CE1FCB.9B8A0920] >> Zachery S. Mitcham, MSA | Information Technology Security Officer| Information Technology Systems (ITS)| >> 910 962 3047|mitchamz@uncw.edu | http://www.uncw.edu/itsd/about/ITS.html |UNC Wilmington | >> 601 South College Road | Wilmington, NC 28403-5616 >> "Security is Everyone's Business" >> [cid:image002.png@01CE1FCB.9B8A0920] AskTAC for self-service solutions and immediate assistance! (https://asktac.uncw.edu/) >> >> NOTICE: Emails sent and received in the course of university business are subject to the North Carolina Public Records Act (N.C.G.S. §132-1 et seq.) and may be released to the public unless an exception applies. >> >> >> >> From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey Schiller >> Sent: Wednesday, March 13, 2013 9:11 AM >> To: SECURITY@LISTSERV.EDUCAUSE.EDU >> Subject: Re: [SECURITY] Administration of PCD DSS Program >> >> Actually there are two different schools of thought here. They address different issues. >> >> 1. Your security should not depend on obscurity. >> 2. Defense in depth, you shouldn't give the adversary any advantage. >> They are not necessarily in conflict. [1] is primarily targeted at developers. As developers your code's security shouldn't depend on the source remaining secret. Because quite frankly, the bad guys will get a copy and if you hide "secrets" in your code, your code probably isn't that secure in the first place. >> >> So when developing systems, [1] should be your guide. >> >> [2] is more often associated with operational practices. Here the attack surface isn't always technical, it is human oriented. I.e., the attacks here are social engineering related. Letting the attacker know the chain of command only makes it that much easier to launch a social engineering attack. Ideally the principals of [1] *should* apply here, but thousands of years of human experience demonstrates that it doesn't always work. >> >> So in summary you should do [1] when developing code (and procedures) but do [2] when it comes to operational concerns. >> >> -Jeff >> >>
Message from hhoffman@ip-solutions.net

I honestly think that's a mis-interpretation but to each their own. Visit the list web-page for unsubscribing, or send a unsubscribe command to the listserv email address. Or just lurk. You might find valuable information. Cheers, Harry On 03/13/2013 09:47 AM, Mitcham, Zachery S. wrote: > This is exactly what I'm saying. Excellent interpretation and reading between the lines > > Zachery S. Mitcham, MSA > > > On Mar 13, 2013, at 9:46, "Harry Hoffman" wrote: > >> I don't understand what you are trying to say with these URLs. Is it >> that somehow these hacks happened as a result of open discussions? >> >> Or are you just saying that hacking is possible? >> >> Or something else entirely? >> >> Cheers, >> Harry >> >> On 03/13/2013 09:17 AM, Mitcham, Zachery S. wrote: >>> http://tech.mit.edu/V132/N62/hack.html >>> >>> [cid:image001.gif@01CE1FCB.9B8A0920] >>> Zachery S. Mitcham, MSA | Information Technology Security Officer| Information Technology Systems (ITS)| >>> 910 962 3047|mitchamz@uncw.edu | http://www.uncw.edu/itsd/about/ITS.html |UNC Wilmington | >>> 601 South College Road | Wilmington, NC 28403-5616 >>> "Security is Everyone's Business" >>> [cid:image002.png@01CE1FCB.9B8A0920] AskTAC for self-service solutions and immediate assistance! (https://asktac.uncw.edu/) >>> >>> NOTICE: Emails sent and received in the course of university business are subject to the North Carolina Public Records Act (N.C.G.S. §132-1 et seq.) and may be released to the public unless an exception applies. >>> >>> >>> >>> From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey Schiller >>> Sent: Wednesday, March 13, 2013 9:11 AM >>> To: SECURITY@LISTSERV.EDUCAUSE.EDU >>> Subject: Re: [SECURITY] Administration of PCD DSS Program >>> >>> Actually there are two different schools of thought here. They address different issues. >>> >>> 1. Your security should not depend on obscurity. >>> 2. Defense in depth, you shouldn't give the adversary any advantage. >>> They are not necessarily in conflict. [1] is primarily targeted at developers. As developers your code's security shouldn't depend on the source remaining secret. Because quite frankly, the bad guys will get a copy and if you hide "secrets" in your code, your code probably isn't that secure in the first place. >>> >>> So when developing systems, [1] should be your guide. >>> >>> [2] is more often associated with operational practices. Here the attack surface isn't always technical, it is human oriented. I.e., the attacks here are social engineering related. Letting the attacker know the chain of command only makes it that much easier to launch a social engineering attack. Ideally the principals of [1] *should* apply here, but thousands of years of human experience demonstrates that it doesn't always work. >>> >>> So in summary you should do [1] when developing code (and procedures) but do [2] when it comes to operational concerns. >>> >>> -Jeff >>> >>>
Point taken, Cheers. ~Daniel
Greetings, As a reminder, this listserv is an open forum and anyone is welcome to join. The list archives are public. All participants must follow the participation guidelines: http://www.educause.edu/discuss/constituent-and-discussion-group-partici... You can manage your listserv subscription by visiting the Security Discussion Group's web page and selecting the "My membership" button: www.educause.edu/groups/security If you have questions or concerns, please feel free to contact me directly. Thank you, Valerie Valerie Vogel Program Manager EDUCAUSE Uncommon Thinking for the Common Good direct: 202.331.5374 | main: 202.872.4200 | educause.edu -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY@LISTSERV.EDUCAUSE.EDU] On Behalf Of Mitcham, Zachery S. Sent: Wednesday, March 13, 2013 6:46 AM To: SECURITY@LISTSERV.EDUCAUSE.EDU Subject: Re: [SECURITY] Administration of PCD DSS Program I suspect that it is the result of intel gathered over public venues, footprinting, social engineering,etc Loose lips; sink ships Please consider closing this thread to the public or send me information on how I can unsubscribe. Thank you Zachery S. Mitcham, MSA On Mar 13, 2013, at 9:41, "Jeffrey Schiller" > wrote: Well. I suspect this was the result of the password database breach at EDUCAUSE. -Jeff
Message from jnunnally@harding.edu

 
So are we suggesting that we need background checks to join a listserv?  Even if we close the listserv and the archives to subscribers only, it does not stop the miscreant from subscribing and lurking.  I have even heard there are SALES PEOPLE lurking on our lists!  AAAAAHHHHHH!!!!!!

 
John Nunnally, Manager
IS&T Network Services
Harding University
 
 
 


Message from hhoffman@ip-solutions.net

Who is this we? My feeling on this list is that there's a valuable bit of conversation that takes place here. Do some people post too much? Perhaps. I'll be following up with some sales pitches from my consulting company, run on the side ;-) Maybe the monthly listserv reminders can state it's a open list, for those who weren't aware of it before. Cheers, Harry On 03/13/2013 01:30 PM, John Nunnally wrote: > So are we suggesting that we need background checks to join a listserv? > Even if we close the listserv and the archives to subscribers only, it does > not stop the miscreant from subscribing and lurking. I have even heard > there are SALES PEOPLE lurking on our lists! AAAAAHHHHHH!!!!!! > > > John Nunnally, Manager > IS&T Network Services > Harding University > > > > > >

Same for us, the Treasury office is responsible and hired a position just for this – but there is a great deal of help from Enterprise Security and the ISO office.

 

Brenda B. Gombosky,

CISSP, CISM, CGEIT, CRISC, CHSP, C|CISO

Director, IT, Enterprise Security

University of Louisville

Information Technology

brenda.gombosky@louisville.edu

(502)852-5037 (Work)

(502)417-8484 (Cell)

 

Message from hhoffman@ip-solutions.net

Yeah, I'd imagine it's pretty much the same everywhere. Treasury knows how to deal with the financial aspects but aren't IT savy so they call in the IT department as a key stakeholder in the process. Cheers, Harry On 03/14/2013 10:06 AM, Gombosky,Brenda B wrote: > Same for us, the Treasury office is responsible and hired a position just for this - but there is a great deal of help from Enterprise Security and the ISO office. > > Brenda B. Gombosky, > CISSP, CISM, CGEIT, CRISC, CHSP, C|CISO > Director, IT, Enterprise Security > University of Louisville > Information Technology > brenda.gombosky@louisville.edu > (502)852-5037 (Work) > (502)417-8484 (Cell) > >
Close
Close


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.