Sunday, December 13, 2009

Local Admin Rights for User: A Losing Battle?

I presume the primary reason for preventing local users from having
admin rights on their desktops is to keep them from installing "evil"
software.

If this is so, then my question to the group is "how long does it take
a desktop user to get a legitimate piece of software installed on
their desktop?" In other words, I have to use software package "A" to
do my job. How long does it take for "A" to be installed on my
desktop? My informal straw poll respondents noted the time range to be
anywhere from 1 day to 2 weeks.This is completely shocking to me.
Now, if my boss is breathing down my neck to finish a project by
tomorrow & I need software "A" to finish the project, I can't wait 1-7
days. The business process will trump this security process and a) I
go up the mgt chain to get an exception b) I bring in my personal
computer, load software "A" on it and get the job done.

So, I wonder why there has never been a survey with the question "How
long does it take to install a software package on a user desktop if
you restrict local admin rights?". This is the root cause of the
"never ending battle" that I keep hearing about. If you make the user
responsible for whatever they load on their machine AND enforce that,
then what is the danger of letting them do so? Well, people with no
local admin privs can still "infect" a machine by using their browser
so once again, what do we accomplish by "preventing" them from loading
software? Seems like nothing is accomplished, hence, the "never
ending" battle.

Call me silly, but I think there is an end to this battle but we don't
want to put in the effort to accomplish this. That end involves a)
enforcing user responsibility for their actions b) give them basic
training (you want to be able to install stuff, you have to sit in
this training) c) speed up legit software install requests.

I keep hearing about this losing battle with the users so why not
think of something radically different?

Just a thought for the holidays....

Tuesday, November 10, 2009

Pretty Fine: Every Guy's Nightmare

Every now and then I tell this story during our concerts as an intro to one of our songs.

This story is dedicated to all of the guys in the world who've made a fool of themselves. You know who you are.

I went to a Catholic high school and as you might imagine, contact with members of the opposite sex was limited to twice a day meetings. On special days, like religous holidays or school assemblies, we got an extra boost of the opposite sex.

The entire architecture of the school was designed to maintain this separation. The teachers were the Christian Brothers (of wine fame) and the Sisters of the Immaculate Heart of Mary (IHM). The school was a T shaped building complex with the stem of the T containing those facilities that couldn't be duplicated because of cost. Facilities like the cafeteria, science labs, gyms, library were fertile grounds for all sorts of adolescent mischief and fantasy, no doubt caused by exposure to the opposite sex. The Boy's and Girl's divisions were in the cross bar of the T. Boys occupied one side in a building painted in light blue and the girls occupied the other wing and yes, it was painted pink. These two wings were separated from the main stem by aerial walkways. We always imagined that individual wings could be isolated in the event of an impure thought by one of the adolescents with raging hormones. Which brings me to the point of this story......

I had a crush on a girl in my class. There, I said it. Guys, you know what I'm talking about. It was that type of crush where I memorized everything I could find out about her. She played basketball and I watched those games from the stands. I knew if I sat in the front desk by the door, I could see her walk by during class change. I knew that if I sat in a certain area in the cafeteria that she would look in my direction and wave. It wasn't until later (after returning her waves) that I realized she wasn't waving at me but rather at someone sitting behind me. Yes, I was a wave interloper, committing the worst faux pas, that of the return wave not meant for you. What a dork!

I remember the day well. It was a Saturday afternoon, early spring, crystal clear sky with just a hint of high clouds, temps in the 60's. It was that type of day that you knew only good things could happen. I came out of the gym heading to the exit where my dad was waiting for me. I have a basketball in my hands and had a pretty good game which for me meant that I didn't throw away the ball and I actually made a foul shot.

As I walk down the hallway, I look up and there she is. The object of my unrequited affection, the person with whom I had countless conversations in my mind, the smartest, coolest chick in the world and she was heading in my direction! This was my chance to atone for those return waves, those smiles, my invisibility. This was it! This was my chance to impress her with my command of the English language and my obvious athletic abilities.....the basketball, that orb of power and status in the high school world.

She approaches and I notice that she is looking at me. I KNOW there is no one behind me this time. There is no chance of mistaken identity. Because I was a musician and practice was a skill ingrained in me, I run through the upcoming conversation in my head:

Her: how are you? Haven't seen you in a while!
Me: Doing pretty fine, how are you! I see you're wearing running shoes. You must be a jogger.
Her: You're smart and I was going for an ice cream cone. Would you like to join me?
Me: Of course, I like nothing better than an ice cream cone after a hard day of basketball practice in the gym behind me where you're heading after talking to me.....
Me: Focus! Focus!

I find myself getting closer to the wall. In fact, I'm getting so close to the wall, I'm tracing the mortar indentations on those cinder block walls. Focus! Be cool! This is your chance to impress her with your wit, smarts, musical and athletic talent. She's looking at me now and I'm starting to sweat. No problem! I just came out of the gym. She'll just think I had a hard workout.....oh yeah, my cool factor will jump up when she thinks about that. Yep, she's definitely looking at me and drifting to my side of the hall. Ok, time for the cool walk!

She's now 5 feet, 4 feet, 3 feet away and she stops in front of me and says:

Her: Hi there. Do you know what time it is?

I still remember the moment I replied to her simple question. It was 40 years ago and I remember every detail of the hallway, the lighting, her looking up at me with those inquiring eyes, that smile, those running shoes, the graceful way she held her hands, the feel of every nub on the basketball I was holding. To this day, I remember those things along with those words spoken by me so eloquently, so polished, so impressive:

Me: Pretty fine, how are you?

copyright 2009 randymarchany

The Neighborhood

The Sunday ritual is always the same. I take my mom to church, and then we stop for lunch and afterwards, go visit my dad. My parents have been separated for 5 years now after 61 years of marriage. Someone asked them on their 55th wedding anniversary how long they’d been married. My dad answered “56 years” and my mom dope slapped him and said “it was 55 years”. My dad sighed and said “it seems like 56.” It was obvious the separation was going to happen but I suppose they were hoping it wouldn’t. Seems silly to me that mom wants to visit my dad after they separated but I guess it’s one of those things that I don’t understand.

My dad’s neighborhood is a nice place with long sloping greens that have the telltale lawnmower tire tracks that leave geometric patterns resembling Incan Nazca lines etched in the grass. The neighbors always have bright flowers that contrast with the lush spring and summer greens and yet still look good with the fall and winter browns. Mr. Simon, my dad’s new neighbor moved in the neighborhood recently so I don’t know much about him. Mrs. Hodges arrived about the same time my dad did. I continue walking and stop by to straighten out Sgt. Brown’s flowers outside his door. He was a Marine and a Korean War vet. I can imagine hearing him “talking” to his troops. I look up and see mom talking to dad from Ms. Collette’s place. Someone always knocks her flower pots over and I pick them up for her. She doesn’t thank me but I get the feeling she appreciates the effort. I start to swing back toward my dad’s place when I get to Mrs. Schaeffer’s place.

The separation has been hard on my mom and I head back to my dad’s place before my mom gets upset with him. Sometimes she gets frustrated with him and I have to listen to her rant about something he did. As I walk up the hill to his place, I see some new neighbors have arrived. One family appears to be a dad and his teenage son, a 16 year old kid. I’ll have to check later to see if he got his driver’s license. My dad’s immediate neighbors have their flowers out and they brighten up the place. My mom always complains that my dad’s flowers aren’t as good or pretty as his neighbors. What can I say? I come up to my mom and gently tug on her arm to let her know it’s time to go. “Who’s the new neighbor?” she asks. “The Youngs”, I reply, “I don’t know much about them.” My mom straightens out my dad’s entrance, always fussing with the plants. I check his entrance one last time and clean his nameplate, “Carlos Marchany, 1904-2004” before we leave only to return next Sunday.

©randymarchany, 2009

Thursday, October 22, 2009

Why Security is Difficult in the EDU world

Just a basic observation on my part that's based only on my experience.

1. EDUs have 2 distinct and competing functions from a security viewpoint:

a. Corporate Network - as much as we don't like to admit it, the administrative business functions (Payroll, HR, Registrar, Grants, Athletics, etc.) have the same security requirements as any corporation. We are in the business of education. We have a product we sell (an education). We aggressively compete for customers (prospective students) at the academic, managerial and athletic levels. Our org charts are similar to corporations (Board of Visitor/Regents/Directors > President>VP, etc.). Corporations sponsor stadiums, TV shows to market themselves. EDUs have football/basketball teams :-). We have to deal with regulatory compliance with Federal, state, local regulations and laws. This corporate function allows the EDU to function as a business.

b. ISP - all of us have on-campus students who use our network for basically whatever they want. In most cases, these are individually owned machines. We provide a network service and get (at least we should) out of the way except to ensure no hogging of network resources. This is exactly what an ISP does. Researchers and faculty can fall under this category as well. The main difference is that they may use a mix of individually and university owned machines. This ISP function allows the EDU to function as a "school" or "research lab".

There is a common set of security protocols/requirements that span across both worlds. This forms the baseline security requirements of your institution. The Corporate Network component, however, requires more stringent controls and procedures. The successful EDUs (from a security standpoint) are the ones who tailor their security requirements to fit the particular function of the EDU. Both functions need a common baseline security model. Sometimes, it makes no sense to apply a more stringent on the ISP side of the house. When we carefully analyze WHY that requirement was imposed, we find that it was most likely due to staff limitations. In other words, the "there are more user than sysadmins to manage them" scenario which causes the few (sysadmins) to impose tight controls in order to impose "order" on the many (users). (hmmm...sounds like a government class...:-))

My experience has shown that if we fail to analyze the "actual" security requirements of a particular function and create a security paradigm that interferes with the business process, then we open ourselves to security issues. In other words, the business process wins. The "art" of building a successful security posture comes from a) knowledge of the business process and how a security requirement will impact that process b) tailoring both the business and security processes to allow the job at hand to be completed c) getting the backing from your Board of Vistors/Regents/Directors.

Monday, September 21, 2009

Are we being hampered by insecure vendor software?

Well, it's that time of the year when EDU IT staff recover from the initial "school's back in session" marathon. Now, we get to evaluate vendor software offerings for a wide range of IT services ranging from remote desktop support, data encryption to physical surveillance.

Got a tweet from someone saying ""Colleges' decentralized IT systems & open networks are a recipe for the disaster we've experienced." http://bit.ly/3wfwy". I found it interesting that that a group founded by "consumer advocates and experts from the financial industry and law enforcement" rips into EDUs for being the source of most data breaches. One only has to take a look at the Chronicle of Data Breaches at www. privacyrights.org to see that this isn't really the case. In addition, the group doesn't attempt to examine the causes of these breaches. Certainly, business practices and attitudes at EDUs can contribute to the problem, they fail to note that in some cases vendor software provides the vector into an institution's sensitive databases.

Time after time, we run across vendors who try to sell us software that is inherently insecure. We're not talking about some obscure race condition in a software module. We're talking about simple things like input validation and sensitive data in the clear. Why do we still let vendors do this to us? A couple of years ago, security researchers discovered that Oracle passwords were converted to upper case, the hashing algorithm was weak among other errors (http://www.sans.org/reading_room/special/index.php?id=oracle_pass&ref=911). Physical surveillance camera systems transmit video images in the clear. Can you say "Look what's on You Tube?". Sure, software has bugs but you know, I'm tired of the customer being the one to discover a security flaw or worse, be victimized by a security flaw. Whatever happened to vetting software before it's released?

Application vulnerabilities now outnumber OS vulnerabilities. For once, the OS vendors finally got the clue and started to release relatively security bug free code. Application vendors on the other hand haven't answered the clue phone. In fact, in most cases, they've taken extensive measures to modify their EULAs to absolve them of any damage their code may or may not cause. Take a look at the EULAs today and you'll find subtle changes in the EULA wording. Years ago, I was interviewed by USA Today and I made a comment about how I was surprised there weren't any software liability lawsuits against vendors who sold poorly written code. I fear that all that comment did was get company lawyers started in modifying the EULAs rather than fix the real problem.

The latest SANS Institute "Top Cyber Security Risks" (http://www.sans.org/top-cyber-security-risks/) confirms application bugs are more commonly the cause of a security/data breach. This paper shows that SQL Injection Attacks and Cross Site Scripting (XSS) vulnerabilities account for ~80% of web application vulnerabilities today. You know, the solution to these attacks is simple input validation. Why aren't vendors testing their apps for these vulnerabilities? If they are, they need to revise their testing procedures. We've found this flaw in numerous vendor apps when we run a simple vulnerability scanner against the product. We're not rocket scientists and if we can find vulnerabilities, surely a vendor can.

It's time for consumers to issue a set of security requirements that must be met before a software package is purchased. This is nothing new. DISA distributed a draft Application Security Requirements doc (Google for it) back in 2003. OWASP has formed an Application Security Requirements Project group (http://www.owasp.org/index.php/Category:OWASP_Application_Security_Requirements_Project) to address this issue. If you want a template that you can modify for your site, take a look at the template doc at http://www.sans.org/appseccontract/ or google for "application security procurement language". This doc is the holy grail for security practitioners but in reality, it will be very difficult if not impossible to find a vendor who would be willing to agree to those requirements.

At least, we'd be putting software vendors on notice that they must take our efforts to secure our enterprise seriously.

rcm, 9/21/09

Thursday, July 30, 2009

Banning P2P? Can you say Antitrust?

I decided to take a break from cyber geek stuff and spend a little time talking about the RIAA/MPAA's efforts to cure the illegal movie/music downloads by forcing sites to ban P2P or they'll get sued.

I play in a band that's won a number of awards and nominations for most of our 9 CDs. We were an early adopter of the www. We were signed to an independent music label and since then have our own label. We market our stuff on a variety of online venues like CDBaby and have the prerequisite Facebook, MySpace, MP3.com etc. sites.

I was asked for my opinion of the Napster lawsuit a bunch of years ago. I made a few observations that I'd like to share here.

1. I FULLY agree that it's illegal to download any form of entertainment in violation of the established copyright laws. However......

2. What if the copyright owner allows free and unlimited distribution of their music, for example. P2P provides an efficient way to distribute that material to potentially a worldwide audience. My band and its record label own the copyrights to our original material and we typically include public domain music on our CDs. We want to market our product and one way to get word out is through the P2P process.

3. So, I wonder if the RIAA/MPAA's efforts to force sites to ban P2P constitutes some sort of antitrust type violation against independent music labels or bands like ours. A P2P ban would hurt our business. We'd be frozen out of potential markets and thereby incur potential loss of income. Again, we are granting permission to distribute some of our materials using P2P. There is NO copyright violation in our case.

4. Public institutions may distribute their own video and audio material via P2P. VA Tech is a land grant institution and its extension service regularly creates videos on a wide variety of agricultural processes. A favorite delivery method is P2P. If a site has to ban P2P for fear of an RIAA/MPAA lawsuit, doesn't that impact their overall ability to get timely information for their site?

More on this later.....

Tuesday, July 28, 2009

Account Sharing - What's the Real Purpose?

IMHO, items listed in a IT security, data security or IT acceptable use policy must be enforceable. The "stick" might be another organizational policy, local, state, or federal laws. If a policy item isn't enforceable, then the policy is worthless.

This brings my discussion to a common policy item: account/credential sharing. Just about every acceptable use policy or standard has a line item that says something like "user accounts must not be shared". The reason for this is primarily to ensure accountability. We want to know WHO was using the account or credential. This makes perfect sense from just about any standpoint.

The first problem is that given most of the technologies that we have in place, we can't really enforce this. Suppose you come to me and say "we want to sanction this person for sharing their account". What evidence can we collect to support the allegation?
  1. account login logs - this item tells us which account was used, when and IP address of the connecting machine.
  2. video logs, room access logs, etc. - these items tell us if the person was physically present at the machine.
  3. personal testimony - These are statements made by eyewitnesses, the accused individual or other individuals related to the case.
The problem with item #1 is that it only tells us what account was used not who used it. The problem with item #2 is that it can only identify who had physical access but not remote access to the target machine. Item #3 depends on someone actually observing the login by another person. Even two factor authentication methods can't give us the "who" part of the puzzle. If I lent you my ATM card (this is a theoretical discussion :-)) and gave you my PIN, the bank just knows that the account was accessed. Their control to gain additional info on the "who" is the video camera at the ATM.

The second problem is that most IT sysadmin staffs violate this policy when it comes to Administrator or root access. Most IT shops have primary and backup sysadmins. They both know the Administrator or root passwords. Best practice dictates that you don't log into directly as "root", rather, you log in under your own userid and then "su" to root. This provides an extra layer of accountability. Remote "root" access is strongly discouraged because we don't know if the primary or secondary admin logged in as "root". We would expect to see a similar strategy employed in the Windows world although I suspect not.

So, as I've mentioned in previous posts, let's try and figure exactly why someone would share their account. Some possible reasons include:
  1. The IT environment doesn't provide a mechanism for a particular business process (see an earlier blog entry). For example, an email system may not have the ability to share an email folder between a dept head and their assistants. The dept head is out of the office and gives the assistants the email password so they can read any important email sent. Another example might be the network doesn't have a mechanism to provide guest access to the net. A visitor needs access to the net and the person logs in under their userid.
  2. The person just wants to let a buddy or family member get online.
Reason #2 seems to be the easiest to claim it's a violation. Reason #1 is a little harder to quantify. I've said before that the business process trumps security. Failure to support a business process will cause people to bypass a control in order to get the job done.

Yes, there are sectors (military, defense contractor, sensitive business, financial) where you can just terminate an employee for account sharing but care needs to be taken to ensure a "wrongful termination" suit can't be filed against you. Military and defense contractors have the easier time with this issue.

What's an enforceable item that will be effective and hopefully accomplish the original goal? A policy/standard statement that says "you are responsible for whatever originates from your account, system." is enforceable. In my previous ATM example, I'm responsible for the disposition of my ATM account.

Policy wonks want to have that "no account sharing" clause in a standard. You should have one to emphasize the spirit of proper account usage. You need to include an enforceable item in your policy that will be the "stick" used in a disciplinary hearing. User reponsibility for their account usage is the way to enforce the "principle" of not sharing accounts.

If our IT procedures can't support a business process, then we may create a situation where users have to share accounts in order to get their job done. Ultimately, this makes us more vulnerable.

Thursday, July 23, 2009

Account Lockout - Has Time Passed It By?

When I first got into the cybersecurity arena, I read all the books that I could find on the subject. There weren't many back then in 1991. A number of the books dealt with securing Unix systems and they all had a section on Account Lockouts. Fast forward to the present and I'm finding myself at odds with the "standard" audit checklist requirement that says you must enable account lockouts. When I teach a SANS class and we touch on this subject, I like to ask my students a couple of questions:
  1. How many of you enable account lockouts?
  2. What's the purpose of the lockout?
  3. Do you have strong password strength rules that are enforced?
  4. What's the purpose of the strong password strength rules?
  5. Do you monitor login fail/succeed entries?
  6. What's the purpose of monitoring login attempts?
  7. Do you notify an offending site that they're attacking you?
  8. How long is the lockout period? Minutes? Days?
  9. How long does it take to reset the account?
Almost everyone said they enable account lockouts and the purpose of the lockout was to prevent brute force password attacks. 90% of the students replied that they have strong password strength rules (and they enforce them :-)) and the purpose of the rules is to prevent brute force password attacks. Surprisingly, about 40-50% say they monitor login failures and/or successes. Those that do say they do this to detect brute force password attacks. 20-25% said they notify an offending site that some host in their domain is attacking them. I found this stat a little disturbing but that's a subject of another post. The account lockout period ranged from 1 minute to "forever". The reset time had pretty much the same time range as the account lockout period.

So, what's the problem? Suppose my attack is simply to lock out all of the accounts on the target. In the Unix world, a good sysadmin would prevent remote root logins and use the su and sudo commands to switch into root mode. An account lockout on their account would force them to drive to their operations center and physically walk up to the server to log in as root. An attacker could take advantage of this time delay to launch their attack. This happened to me back in 1997.

Back in the old days of Unix (late 80's-early 90's), Unix did not have password strength controls built into the OS. There were tools like npasswd, passwd+ that allowed such control but you had to build the commands manually. The absence of such controls left account lockouts as the only viable defense against a brute force password attack.

Nowadays, password strength rules enforcement is built into the OS usually in the form of PAM modules. The admin has a wide variety of builtin tools to mitigate brute force password attacks.

One of the things I always ask my admins is "does the security control introduce a worse problem than what we're trying to solve?" I believe account lockouts do just that. A massive DOS attack against your user base is worse than someone brute forcing their way into an account. Your password strength rules, log monitoring, notifying remote sites provide adequate defenses against a brute force attack. IMHO, account lockouts are an archaic solution to the problem. It's what I call an "inherited security solution". It was in an 1st edition security book and left in there with each new security book without realizing other controls are better.

IT Audit checklist will usually flag the lack of a lockout strategy as an audit item. It's time to update those checklists.

Tuesday, July 21, 2009

Security and the Business Practice

We're often asked to provide an opinion on the security of a software product. We do a preliminary analysis of the software for common software vulnerabilities and hopefully, we don't find any. However, there have been cases when we do find one. Does that mean the business unit shouldn't use the software? Well, we ask a couple of followup questions: 1) is this software needed to run your business operations? 2) Is there another software product that does the same thing but has no software vulnerabilities. Obviously, if the answer to question 2 is "Yes", then we'd recommend purchasing that product. The worrisome situation (from a security standpoint) is when the answer to question 1 is "Yes" and the answer to question 2 is "No". One of our security paradigms is that the user be aware of any security vulnerabilities and accept the risks of using such a product. So, what does "accept the risk" mean? Well, the first thing is that the business users determine the software product is "essential" to their business process and they are aware of a potential security issue with the product. The second thing is that they devise additional procedures to compensate for the weakness. For example, a laser printer that has no access control features might require the purchase of a hardware firewall that will provide access control. The third thing is that the business process owners acknowledge they are willing to assume the risk of using such a product.

We find IT sysadmins focus more on protecting the IT asset rather than protecting the business process that uses the asset. Years ago, a friend of mine got one of the first Macs in her office. After I gushed about how cool it was, she calmly told me that "as far as I'm concerned, that Mac is a stapler. It just helps me do my job. If it weren't here, I'd still have to do my job."

That explains the dilemma that IT sysadmins are in every day. Account lockouts are an example of how protecting the IT asset conflicts with the business process. This is the process where an account is locked out when a user fails to give the correct password after 3-5 attempts. The obvious attack is to simply lock out all of the accounts at once. Why lock the account? It's the easiest thing to do from a sysadmin standpoint. Another example is the practice of restricting where people can go on the web. Presumably, it's to prevent misuse but accessing the web freely is a necessary thing for business use in most university business processes. The way to prevent misuse is to simply enforce the Acceptable Use Policy. Hold people accountable for misuse and we reduce its occurrence. IT staff shortages force sysadmins to make choices that could interrupt the business process. When that happens, people will circumvent the security process because they have a job to do and the security process gets in the way. This circumvention reduces the overall security of the business unit.

So, it comes back to accountability and the willingness of the business to enforce it. Military and high security businesses have it easy. Violate the rules and you're out. It's not so easy in the civilian world and it takes time to find that balance.

The one thing we don't want is for the IT sysadmins to cause a worse security level because of a seemingly draconian security best practice that forces users to go "underground".

Thursday, July 16, 2009

introductions

Just letting you know that I'll be posting my thoughts on various cybersecurity, music and volleyball issues in this blog. More later.