Printable View
hi
say a scenario like this. Staff A poses as the helpdesk and calls up Staff B. Staff A asked for Staff B's password to do some administration stuff..Thinking that Staff A is helpdesk , Staff B gives the password to him. How can we prevent such things from happening.? Security awareness is one way. How about preventing this from a technical perspective. ?
thanks
I'm sorry but I am not very tolerant about any one giving out passwords for any reason. Staff B should be fired or at the very least denied access to restricted (passworded) areas.
Your company SOP's should have policy laid out so that giving a password to anyone on the phone would be a firing offense. If staff A was legitimate they would either already know the password, or have a more secure venue of getting it.
There is not any good technical fix for user stupidity.
Training is going to be the best answer for this. There are some technical controls that may help but the human is the weakest link in any network. Social Engineering is the most effective type of attack out there because people have weaknesses, kindness, greed and stupidity are a few of them.
On way we can prevent the problem would to be implementation of some controls that would require several passwords. One-time passwords may also be effective to a degree.
There is no technical means to prevent this. I know my password. I can speak, too. So unless my computer is equipped with a psychic communications array to hear my thoughts with, and a flyswatter to slap me upside the head with before I give out my password, it can't stop me.
You can limit the impact by enforcing password changes regularly, watching for multiple logins, and limiting physically where passwords can be used.
Another possibility is the use of smart cards, of which employees are issued only one. I have also seen keyfobs with a serial number that changes every 30 seconds or so, which is linked to a password database. That serial number is the user's passwor dfor those 30 seconds. But neither will prevent employees from lending them. The only other solution would be the use of biometrics.
But a technological measure against password sluts would be as impossible as a car that won't let stupid drivers inside it.
The device that's being accessed needs the finger print from Staff B ;)
edit:sorry just saw Strieks part about biometrics.
Have all your workes read the Art of descption by kevin mitnick
kruptos has the answer 'training'.
Staff need to be made aware of the value of their username/passwords and also made aware of the consequences if they hand them out.
If your company doesn't have a password policy and if you do hasn't made an efforet to make staff understand a password policy then you probably won't be able to discipline the staff never mind sack them.
This sort of thing has to be started from the top with policy driven by senior management.
My answer would be to have help desk verify that they are who they say they are and/or not give him the time of day if he doesent show up on Caller ID. Generally you call help desk they dont call you!
thanks for all your input.
The main concern on my part is how , in the scenario mentioned, the staff B is going to identify that helpdesk is who they are.
So firstly, helpdesk should not ask for passwords from users at all. This is enforced by policy.
secondly, users should just say no, no and no when being asked for password (enforced by policy )
lastly, as a identifying mechanism, use caller ID...
thanks
You could have a system where no member of staff is allowed to tell anybody their password (as you currently do) and your help desk call around during quiet times and attempt to obtain a password from users. Those who hand over a password could then be sent on a training course to show them the error of their ways. If the staff know about this process then they will be very suspicioius of anybody who asks for their password.
another thing that is usefull is unannounced security audits. You call up a user, giver them a false name and try to get their password off them. If they respect the companys policies you shouldn't get it.
I used combine this with a monthly or bi-monthly report. Add a password scan with details on how long it took you to get 90% of the passwords in the company and most people sit up and take notice. Especially with things like 25 people out of 50 use "god" as their password. Basically what i am saying is moer or less the same as what has been said before educate your users and communicate the importance of security to them.
If you're going to do something like that make sure whoever is going around trying to get teh passwords has a written note from senior management detailing that they do have permission to do this. If you do this without a 'get out of jail free' note you could still end up in the **** even with the best of intentions.Quote:
another thing that is usefull is unannounced security audits. You call up a user, giver them a false name and try to get their password off them. If they respect the companys policies you shouldn't get it.
I could imagine a slightly worse scenario. Staff A walks over to the desk of Staff B and asks him for his password because he needs it on some other system. Staff A and B have been collegues for a few years. So Staff B sees no problem providing Staff A the password.
However, Staff A will leave the company at the end of the month and is planning to copy as much information as possible for his new employer. So by collecting passwords from other staff members he can access all this information and possibly hide his true intentions for a long while.
So A uses the usernames/passwords from B, C, D, etc. to collect as much as information as possible and manages to store everything on an external USB harddisk before he leaves the company, knowing his new employer will reward him handsomely for the information.
You could assume that it all depend on the level of value and importance of the data that people can access. Unfortunately, someone who wants to get inside would start at the weakest link, which could be the users with the most limited access to the important data. But by using information from this user, they can manage their way upwards in the hierarchy until they gain full access. Like going up some stairs, step by step until they reach the level they want.
A system I have seen is where each workstation has a unique ID as does each user. You could only login from your workstation using your ID and password. In that scenario your details were useless unless someone had physical access to your workstation.
:)
Social Engineering is the most common way to break into networks. All the new helpdesk guys get a call from me pretending to be Frank Rizzo. I am usually sucessful in gaining access. Then they get scolded the next day.
I don't know about the most common way to break into networks. But I guess the possibility stands there. But in dealing with my own experiences with this sort of thing, sometimes it helps to mention Social Engineering at an office conference, or talk to the help desk people personally, it all depends on how big the company is. Because if you have 50 help desks with 10 people on each, that's alot of people to warn;). Sometimes its best to contact the CEO or the person dealing with everyone. But why am I rambling about this ? I have seen actual incidents where someone from the same company would call a help desk to see how much system information he could get from them as a test to their loyalness to the company. Maybe more people should start doing this.
-N (Good to be back)
I believe the saying goes
Quote:
There is no patch for human stupidity
Quote:
Staff A walks over to the desk of Staff B and asks him for his password because he needs it on some other system.
Bzzzzzzzzt wrong answer.
If staff A legitimately requires access to a system he does not currently have access too s/he must go through the proper channels to recieve their OWN set of credentials.
In the case of admins, each admin user should have their own admin account for carrying out the required tasks.
If each user has and individual ID it provides an audit trail to identify who caused a problem if a problem should occurr.
If staff B gives their password to A they break the audit trail. According to policy staff B is now responsable for the actions of staff A. + if I find out they are doing it I would take action with their line manager to prevent this happening and I would push it to a disciplinary if anything did happen.
Sharing passwords is the 8th deadly sin.
It goes on a lot though and in the same context as said. I'm investigating our application developers right now and some of the major recommendations in my report are to get them to stop using communal admin IDs and sharing passwords.
Well, okay. Other situation then. Person A from an external colsultant agency tells Staff B that he needs to have a password for system X right now. It doesn't matter if this goes through the official channels for him, he also notes, because he just gets paid by the hour. If the regular channels would take half a day or more to provide him the password, then he doesn't care. Means he's there just half a day doing nothing and getting paid for that. So some employees might think about this and decide to save the company some cash. :) Of course, that's not always smart but people tend to be too trustful at occasions.
Of course, a very brutal social engineer might just fast-talk his access into a whole building, trying to sneak inside with other employees and at one point he just says he's been sent there by some consultant agency to modify something. Maybe he even has some forged documents that seem to make his claims valid. Of course, this would be extremely rare but when the stakes are high and the information extremely valuable, some people might go as far as this.
Basically, alwys keep track of the weakest points in your security and be aware that when you strengthen one weak spot, some other spot will become the next weak spot...
Hi there katja does the name Kevin Poulsen ring any bells ??Quote:
Of course, a very brutal social engineer might just fast-talk his access into a whole building, trying to sneak inside with other employees and at one point he just says he's been sent there by some consultant agency to modify something. Maybe he even has some forged documents that seem to make his claims valid. Of course, this would be extremely rare but when the stakes are high and the information extremely valuable, some people might go as far as this.
Or you could always just apply for a job and if you end up getting it you just avoided half of those steps ... Or you could always blackmail someone and do it that way ... Or you could bribe someone to get the info for you ... The possibilties are endless ...
B.T.W. Why do they call it social engineering why not just pathological lying ???
Hi Agent... The reason why they call it social engineering is because they don't always have to tell any lies. All they have to do is pretend they need help accessing some system. Many people tend to assume things and are willing to help even a total stranger who turns up at the office and says he needs access to one of the system and thus needs a password.
He's in the office so he's either an unknown collegue or some outside advisor and not everyone tends to question them why they need access. There's a job that needs to be done and they don't want to waste time on "formalities"...
"Hi, I am new here and need to access system X. Do you happen to know the password?" is a short and very true statement for such a person. It's not a lie, but he knows the other will assume he's a collegue or some hired help.
Do you know how many laptops get stolen from offices? Some stranger just walks inside with the other employees trying to avoid any security checks. They just look around for an abandoned laptop and once they find one, they take it and walk outside again, with the laptop. And it might take days before someone realises that the laptop isn't stored in some safe place but actually got stolen. Maybe even longer.
Kevin Poulsen? :)
Humans are the weakest link in any IT system. Always have been, always will be.
Staff need to be aware of the concequences of their actions. 'Aware' being the key word. The only way to defeat a social attack it to have staff trained to expect it and knowing how to deal with it. We are in the process of building a staff infosec awareness program which will cover password responsibilities and social engineering.
After which they should know that if they give out a password to an external agency without authorisation they will be collecting their last pay check soon after.
Now you're starting to talk about risk. If the assets you are protecting are extremely valuable it starts to make sense to protect against the unlikely and to take more outlandish measures.Quote:
this would be extremely rare but when the stakes are high and the information extremely valuable, some people might go as far as this
I think Catch is very knowledgable about risk and managment of protectively marked materials etc.
I think that we are slightly losing track of fundamental security principles?
1. All users have a unique ID and password.
2. Users are authorised to do ONLY what they need to do to perform their job function. No more and NO LESS (that way they have no reason to ask for help?)
3. Identification must be worn at all times.
4. Strangers/visitors must be identified to employees by line management, and their terms of reference clearly stated. Any deviation must be authorised by line management.
5. Where practicable, users should only be able to log on once, and only from their workstation.
6. Applications and databases should only be available during permitted hours.
I have no problems with shared passwords and IDs where these are purely "look up" applications of a non-sensitive nature. Basically, I mean "read only" stuff like part numbers, library books etc........where you only have an ID and password because the system requires it.
Many security problems can be put down to sloppy policies, ignorance and poor management.
:)
Also in any organisation you will have different levels of security for different job profiles. The level of security needs to be relative to the responsibilities of the job. The biggest problem with security is often company’s go from one extreme, no security policy, to the other extreme of too much security. The end result that is that the policy is often ignored as it is too restrictive to the business of the company.
Security awareness needs also to be instilled from the top down. It is not much good to have the mail room worrying are their passwords able to stand up to a brute force attack if the financial director is walking around with his password taped to the screen of his laptop.
Good points, nihil! Very wise comments but unfortunately not everyone listens that well to good advise. Let's consider possible weaknesses in those rules...
1.) Sometimes several people will all need access to the same system regularly. Think about a cash register system in a restaurant or shop. Of course, such a register won't provide lots of access but it might still contain some valuable data. (For example, the amount of cash in it.) Of course, with proper hardware the employees might never need to access the computer system behind it but it's still there. And I think there can be other situations where multiple employees share the same computer system because they just need it once in a while.
2.) The biggest problem is determining how much access someone needs. In general, a software developer will need lots of access to the system they are using. They might even need to install all kinds of additional tools on a regular basis. And unfortunately it's not always possible to finetune a system to the exact needs of the employee.
3.) Identifications can be forged or even stolen. It would not be that troublesome for someone to just make a copy of such an identification. Or use the identification of someone with more access. Especially when identifications get copied, things become quite difficult. Which is why biometric identification tends to become more popular.
4.) If you're in a big company where many people walk around many different departments, it does become a bit difficult to identify someone as a stranger. If a building has over 2000 employees then keeping track of strangers becomes quite challenging, simply because most people are strangers for all others. Besides, strangers might have all kinds of different ways to get inside a building, with walking through the front door as one of the most daring techniques. But climbing through an open window or through an open fire-exit is also a good way to get strangers inside. With a fire-exit, a regular employee can even just open the exit for a stranger in return for cash or whatever else.
5.) Not always practicable, but it would be reasonable secure. Problem is that some systems are needed to be shared between multiple users. For example, consider a company where people are developing a client-server application. They would need access to multiple systems to test their work, and preferably need administrator access. Test systems tend to be systems where multiple employees share a single account to access the system. And sometimes this test-account might have too much access to the whole system simply because one of the developers needed this access.
6.) In a 24-hours economy there are many applications that must run 24/7. A helpdesk will need continuous access to the helpdesk database. And although people will just work 8 hours per day, there's always a team that will take over their shift. (And sometimes those helpdesk people are located on different parts of this planet so these teams always work during the day. One team in the UK, one in India and the third in Brasil and you have a requirement for 24/7 access.
But still, you make very good points. It's just that poor managers will find poor reasons to ignore these simple rules.
One other consideration is when companies start to outsource their projects and those external companies need access to possible sensitive company data. How much access should they be given and how to check that they keep the information you provide them as secure as possible. In that aspect, outsourcing could be a real security problem. Unfortunately, it's also very inexpensive and thus a reason for management to choose this option.
Katja
1. You are talking retail (EPOS) here. The only way to access the system is via an enquiry or a transaction. As people (customers) don't like to be kept waiting these systems are usually driven by a swipe card, key, token or whatever. As your performance is measured by your transactions, you would not want someone else's identity.
Anyone else has ID: Password: Workgroup: Profile. If they need to do things infrequently, then the task should be delegated to an authorised expert, remember "infrequent" often means "inaccurate".
2. Developers should not be allowed anywhere near the live production systems.
3. Beyond the scope of social engineering............more like breaking and entering?
4. "Walking around" :eek: that means they are not working.................we are now looking at some serious business process re-engineering requirements. There are also some quite nifty electronic surveillance and access control systems I have worked with.
5. See #2 above. You need a complete test environment or you will not be able to do End-to-End and User Acceptance Testing.
6. No problem you can run it on a "shift system" based on location/timezones.
Outsourcing?....................you do NOT give them sensitive data. You have the database design specifications, file layouts, screen layouts, transaction specifications, etc....................you give them test data which you have invented.
:)
1. Retail is one area where many people can have access to the same system and often overlooked from a security viewpoint. Especially when people pay with cash, it's quite easy for someone who operates the system to steal small amounts every day hoping it won't get noticed. With access to the system they could even hide all traces if they know how they should modify the system. Then again, in retail many people operate the system through some additional hardware that is linked to the computer and never really have to deal with the computer itself. Still, the computer is often located very close to their work area.
2. True! But developers do need some data to test with and often such data is just retrieved from any live systems. A system that is processing financial transactions would need some transaction data from a live environment just to make sure it works fine with it. Will companies take the trouble to create just spoof transactions for testing purposes or do they trust their developers well enough to provide live data?
3. True. But breaking and entering is one way to collect sensitive information, especially if it's stored in laptops, small PDA's and mobile phones. Or maybe loose CD-roms or external disks. Or even those small flash-disks! A secure system does also include making sure no sensitive data can be found on very portable devices.
4. Well, walking around could happen from their work area to the local canteen or even to the exit for a sandwich in the sandwich store next-door. Or maybe for a visit to the toilet. Or maybe someone needs to find someone else in another department. People will walk around the whole building. (They might just admire the architecture.) Of course, a good surveillance system would help but how many companies are really willing to invest a lot in such systems?
My dad told me about a company he once visited. He saw security camera's all over the building and thus asked one of the employers if they felt it affected their privacy. The employer didn't care and pointed out that all camera's were just made from cardboard and not at all operational. :) Rather than making things secure, they just made it appear secure...
5. As 2, indeed. But test environments sometimes use data from live sources. (Means they have read-access to those sources.)
6. Shift system? Never thought of that. Now, I'm not a manager so I assume that managers will think of such a system. :) Yeah, I'm young and innocent...
Outsourcing also has the same problem as with regular development. They will need some kind of data to test their systems with. Creating (spoofed) test data costs time and thus money so many companies just provide data from live systems. This means that outsiders have read access to what could be sensitive information. This is especially a problem when a company just needs a small project to be outsourced. The time required to generate test-data could be more work than developing the whole project and testing it with test-data retrieved from the live system. Think about situations where thousands of records need to be processed within a small amount of time. You can only test this with large sets of testdata.
In my opinion, most security risks occur because someone wants to save some time, because time equals money. And these days, things need to be done fast, and often have to be finished by yesterday. So a good rule I've heard from my dad is that if something saves you some time, consider if it also increases any security risks.
Katja
You tell them the rules and they invent the data................otherwise don't outsource to them? as in: "show it to me as you think it works" and I will tell you if you followed instructions and have a half chance of getting paid sometime :DQuote:
Creating (spoofed) test data costs time and thus money so many companies just provide data from live systems
As for live systems.................any developer who is caught even thinking of going near them is shot! :ubergun:
What you do (as a workaround) is go to Infrastructure Support/Operations and tell them to restore any required files to the development/test system from backup.............that does not compromise your SLA with your users?
Hey Katja.................the sooner you start thinking like a manager, the sooner they will make you one. Unfortunately, this does involve some politics?
Also remember that real test data could be subject to legal compliancy?
:D
Okay, so you tell the other company what the data should look like and tell them to generate their own testdata. And so they will, and charge you two additional weeks that they will need for generating the testdata.
So, not only does it mean that the company has to pay more, but the project will also be delayed for a fortnight. Many managers want things to be done as cheap as possible and as fast as possible so they are tempted to just provide some live testdata from their systems.
And well... I am considering to become a freelance developer so I'd probably become my own manager. :) I already have a few contacts but want to finish my studies first. It's not an easy job since I will have to do several things at the same time. Write code, advertise my abilities, contacting and visiting customers, designing products and even testing it all. But it looks a real challenge for me. :D
But that also explains my view on security. I look at it from a developers viewpoint, who needs full access and yet also a secure environment. As a developer, I don't care much about where any test data originates from, as long as it doesn't cost me any time to generate it. I'd have to charge more for something that's not challenging. :)
Aside from educating your users about not giving their passwords out, you also need to educate them on choosing a GOOD password. As mentioned above, MANY people use passwords such as "god", "password", "administrator", etc...Quote:
Originally posted here by MURACU
Add a password scan with details on how long it took you to get 90% of the passwords in the company and most people sit up and take notice. Especially with things like 25 people out of 50 use "god" as their password. Basically what i am saying is moer or less the same as what has been said before educate your users and communicate the importance of security to them.
A good password should include both letters and numbers as well as - if possible and allowed - special characters. examples would include the following (and these are just made up):
x5629SdP@kdO&9177
DaTa20013&Steady67@17836DpO
While many places limit the length of a password, I have always felt that people should be able to set their own PW lengths as long as they are able to remember them. Hence in my company, all employees are not only encouraged but required to set a minimum PW length of 12 alphanumeric/special characters.
Carenath
Quote:
Originally posted here by ghostmachine
thanks for all your input.
The main concern on my part is how , in the scenario mentioned, the staff B is going to identify that helpdesk is who they are.
So firstly, helpdesk should not ask for passwords from users at all. This is enforced by policy.
secondly, users should just say no, no and no when being asked for password (enforced by policy )
lastly, as a identifying mechanism, use caller ID...
thanks
well, as pointed out in Mitnick's book, caller ID can be tricked too, if the S.E is really motivated and skilled....So, it cant be relied upon as a "final id mechanism" 100% of the time...
my $0.02
-z3
A long complex isn't necessarily good. It just forces more people to write them down. We use 8 an 8 character minimum which mush contain numbers, letters in upper and lower case. I think this is probably the upper limit that staff can cope with.
Schneier advises that you can make staff use very hard passwords but you have to let them write them down. Put the note in your wallet. Most people keep their wallets pretty safe.
It's a view that a lot of people are coming round to here. Especially with some pressure for single sign in happening.
I belive the best practice for development within an organisation is to have it on a seperate network logical or physical. Develpment should never occurr on the business network. Development data should be synthetic or at least sanitised but must be analogous with live data.
Of course people tend to fixate on passwords, things like how long is yours, does it have special characters, etc. In my experiance the biggest internal security threat comes from people simply not locking their workstation when they run to get coffee or go to talk to their supervisor, etc. I've had devellopers thinking they were smart and by passing our lock out policy. That stopped quickly after a couple of them left for the weekend and didnt log out. when they came back monday they had sent an e-mail inviting everyone in their team and the tech support team for a drink to celebrate their birthday. :D .
Aspman
Must send that one to some of my RAF mates?..............the compliment generator at the bottom of your posts is a real hoot :DQuote:
You move with the eloquence of disintegrating fuselage.
You are right about the development environment...............hell I would not have any of my team messing in the live environment..............we have a subspecies called "catches" (catch 22 :D )......errrrrr "auditors".................I do not think that they would be impressed?
:D
:lildevil: I am an auditer :firedevil
(a large part of my job at least)
We come in peace.....................shoot to kill................
:zap: :shootem: :ubergun:
I got this one :
You have not yet reached the height of your depravity.
Sounds about right for me.....
As for the rest of it a developer sniffing around a live system :spank:
It's not my fault. They didn't mention the 'A' word when I took the job :halo: