For Users of Software Restriction Policies

Look at this Diary from sans.org today:

http://isc.sans.org/diary.html?storyid=6529

In the second part, the author of mechbgon.com, which has been cited often, describes how, before finding SRP, he used a product that created behavior blocking rules for executables.

Execution prevention wasn't discussed by much of the security industry at that time. Today, it's a component in many of the anti-malware software programs, and, of course, Software Restriction Policies.

----
rich

 

mechbgon to me is an unsung hero in the malware prevention world. I can't count the number of people I have sent to his website for instructions on setting up real Windows security. Prevention and Configuration over detection, what an incredible and liberating concept! Thank you mechbgon. (and Rmus)

 

Disallowed by default=default deny, a security policy that's been around a long time and is extremely effective. IMO, it's the only way that Windows can really be secured for the long haul. I use older vesions of Windows that don't have the built in ability to make software restriction policies, 98 and 2K. SSM performs this function on my system. I've relied on a default-deny security policy since 2005, with 100% success.

The sad part is that most users will not adopt this type of policy because it restricts them as well. They've become so conditioned to Windows default-permit mentality that allows them to do anything from anywhere. Being restricted is unacceptable to them, even if it's for their own good, even if it can save them money on software. I've offered to set up default-deny policies on a few clients PCs. They don't want it. The responses I hear are what if I want to install something, change something, etc. Nothing concrete, just "what if" instances. It boiled down to their wanting to be able to install anything, run anything, and do anything they wanted, including being stupid when it suits them, then expecting their security software to protect them.

Regardless of the enforcement method used, default-deny will only be used by an enlightened few, those who are tired of the arms race mentality of conventional default-permit based security products. Default-deny frees you from being dependent on constant detection updates and the costs associated with them. It relieves the load on your system when every file, process, etc no longer has to be checked against that detection database of known threats. Properly applied, default-deny mitigates zero-day threats, unknown and custom made malware. It prevents vulnerabilities in user applications from compromising the entire system. Vendor support of the OS and user software becomes much less of an issue. Default-deny isn't limited to applications and executable code. It can just as easily be applied to internet access, web content, and the users access to the OS and file system. Ideally, default-deny should apply to every aspect of the system.

With Win2K being my most recent MS system, I can't explore the strengths and limitations of software restriction policies and limited user accounts created by the built in utilities. I can't compare them to the enforcement abilities that SSM provides. From what I can tell by looking at that page you linked to, software restriction policies are easier for the average user to set up. The rules/policies aren't as specific as those made by SSM, but then most users wouldn't want or need that level of control. My primary concern regarding SRP is what I perceive as their limited ability to control interactions between allowed applications, a browser and a PDF reader for instance. On mine, the browser and PDF reader are not allowed to launch each other. The PDF reader doesn't have internet access and is not allowed to parent any process that does have internet access. Can SRP be configured to enforce this specific of a policy? I realize that the SRP would prevent any new executable from running. I'm less convinced of their ability to defend against code that would be executed by a system component such as rundll32, svchost, etc. Then again, if the default-deny policy is also applied to each applications internet access, it can easily be a non-issue.

 

You are spot on with your analysis of what normal peeps want. They do not want LUA at all.

No, SRP does not allow program X to disallow spawning of program Y, only to allow, deny or restrict.

But you have hit the nail on the head of why most peeps don't want or care about security. You and I and many more here at Wilders might take the time to configure our security for such things, but normal peeps, not likely.

SRP is designed in a simpler way than what you are used to. If you do run LUA, the Users permissions are really what give you the security, if you close down some autorun locations and strip ownership of objects and containers to Admins only.

It is the job of SRP to create the default-deny effect. It is fairly straight forward concept, you allow .lnk's to be executed, but not actual .exe's without some sort of exclusion.

The problem is, as you state, no one out in 'userland' wants to be bothered with LUA, much less default-deny.

Again last weekend I worked on a computer I have worked on many times over the years. Ok, newer hardware, but same person lol. I have used many tools in the past, invariably though they managed to muck it up. I was reformatting (again) but at least they save thier data on dvd now Anyway, when I formatted, I created LUA to show them. Put on SuRun and showed them. Did not even go to SRP default-deny. Response? Thanks, but no thanks. We just want to browse the web, check our mail, order things, and sometimes play mahjong etc.

So, next I used my PGS tool, from thier admin account, locked down firefox to BU, locked down MediaPlayer to BU, etc etc. All thier programs that they used daily were put into BU with SRP. I created a folder for thier downloading. I set thier browsers to not ask where to download to, and not to run etc, but to save to that downloads folder. Fortunately these peeps know what an executable and file system is, so they quickly understood that things went to the downloads folder, and you execute it from there. They understood that the downloads folder and thier programs (certain ones) were being 'restricted'. They understood if they started an install from the downloads folder it would not have success because every .exe in it was restricted. They understood to install they must move to different directory, then run it. They could handle this. Almost everyone I help, that scenario is repeated. No one wants LUA. But most can grasp the concept of restricting certain programs and how it effects what they do.

Unfortunately, most peeps I have helped don't really want to use sandboxie either. I put it (nag version) on thier box, and show them how they can test something in it, or surf in it. But most don't use it. They don't want to take the time to understand how the sandbox filesystem is segregated from the real one, and you must recover contents. That is still somethign I am working on, an easy appraoch for them that will make them want to understand sandboxie. I think they need the forced folders feature of the paid version though to make it really stand out as a good addition.

Sul.

 

I've pretty much given up on trying to get users to accept any type of security policy that includes any limitations on them or the software they use. I've told several clients that I will no longer service their systems if they don't change their habits. They're either paying someone else now or living with the consequences of their actions.

Your mentioning SandBoxie makes me think of something I saw in another post in one of the threads here that equated the "sandbox" with a play area where users could do as they please with no consequences. Instead of being an effective security layer, it's treated as permit to be stupid. People using it to test malware and malicious sites on their primary systems and expecting it to make up for their actions. IMO, that's expecting too much of any security-ware. It ranks right up there with "leaktests" that work on the assumption that you've allowed malicious code to execute on your system, something a default-deny policy would not allow to happen. I've also installed SanBoxie on my 2K system. When I have the time, I test its abilities to isolate the permitted applications that make up the attack surface from the OS and from each other. The sandboxed apps are still subject to the same default-deny policies as the rest of the system. Unless it can be embedded into a format that's already permitted, any new malicious code that's designed to test SandBoxie won't get the opportunity to try. IMO, that's how it should be used, not as a single layer standing between modern malicious code and users default-permit mentality. I can see where SandBoxie can be an asset, even with default-deny setups. That said, I'm not yet convinced that it's really necessary. My existing default-deny setup has been completely up to the task for the last 5 years. Once in a while, I'll load up a test system (a duplicate of my primary system) and test it with new exploit code. Except for one time that caused me to change how some file types were handled, the results have been the same. The code couldn't do its job.

 

Execution prevention wasn't discussed by much of the Windows security industry at that time.

Fixed it for you.

 

LUA and SRP make for a great security policy. Trustworthy, free and effective, and it's right there built into the operating system as security should be.

However, any advocates of LUA (and SRP) should always understand their limitations. Knowledge is power.

Unfortunately for Microsoft and the computer using world, the security benefits of LUA (and again, SRP as well) can easily be ruined by such things as big name computer manufacturers changing the default NTFS permissions "for better usability" and software vendors producing software that configures NTFS permissions insecurely during install.

How many people running LUA/SRP know where limited user accounts can really write and execute on their system? How many have checked whether there are folders in %WINDIR% that allow any old user to create new files and execute them (assuming the default deny whitelist SRP policy that allows everything in SystemRoot and ProgramFilesDir to execute)? Things like this should always be tested. Otherwise, bypassing and disabling even whitelist SRPs is not always difficult, if the file system has the default-from-Microsoft permissions set.

But, I digress. I would choose LUA (and SRP) over endless anti-malware programs and HIPS and HOPS and HEPS any day of the week and twice on Sundays.

 

Given a choice, I'll use SSM or the equivalent to set up and enforce a software restriction policy for a couple of reasons.
1, Rules and policies can be made for individual executables as well as locations like the windows or program files directories.
2, The rules apply to all system executables.
3, The interaction between individual executables can be controlled.
4, Switching from user mode to administrator mode is as simple as entering a password.

Personally, I don't like the term HIPS at all. It tells the user nothing about the app, referrs to several different types of software, and has become nothing more than an advertizing buzzword. IMO, apps like SSM should be called process firewalls. The built in tools for building an SRP does much the same thing, but in a less complicated and detailed manner. Each is suited to a different type of user. Either way, it's not the tool that secures your system. It's the policy or rules that they enforce that protects your system. The policy to be enforced should dictate the choice of tools, something that most users get backwards. One creates a well thought out layered security package. The other creates a big pile of system draining security apps.

 

Can you reference some non-Windows security articles prior to 2003 that discuss execution prevention/white listing/default-deny concepts?

In fact it was a UNIX user who introduced me to the concepts, although it was not in the context of using UNIX, but just a strategy that could be applied anywhere.

thanks,

rich

 

The problem with all of these security terms is they have become so widely used in different contexts that they really don't mean anything (especially when used across platforms). As the guy above said, HIPS is so widely used in a variety of contexts that it becomes confusing. And Microsoft has its own name for things - SRP, UAC, DEP, MIC, etc. All of these things can be done on *nix OS's, though it's difficult to nail down some of the minor nuances that someone unfamiliar with non-MS products would easily understand (likewise, I am not sure I understand the MS terminology because I am so used to Unix).

As I mentioned in another post in another thread, what MS calls "DEP" was done first on Unix/Linux. However, there are several "methods" to achieve it. IBM developed ProPolice for stack smashing protection. The GNU compiler also has various options such as FORTIFY_SOURCE and -fstack-protector that does the same thing without needing to apply the ProPolice patch. And then there's PaX which was written as a kernel patch. It does things like ASLR, executable space protection (via the NX bit if available on the CPU, and if not, it emulates it) and heap overflow protection. The PaX team really pioneered ASLR. And Red Hat has done a lot of work, too. They developed "exec-shield" which is essentially a less comprehensive version of PaX. These types of protections (which I think Windows now has in Vista/7, though in a more limited implementation) can help stop a good number of exploits.

But all of that really doesn't pertain to what it appears you mean by SRP (the above are all low-level memory and buffer overflow protections). I believe SRP in Windows is a user-space policy that can be written to flag certain binaries as non-executable and/or flag certain directories so that nothing can execute from them. If I am understanding correctly, then this type of thing has been easily achieved for decades on Unix (chmod a-x directory) without needing any special tools. However, these file permissions on Unix can be overcome if the admin is stupid. For instance, if the user gives a malicious binary his root password, it's game over regardless of the file permissions imposed on the executable. But this applies to Windows too (LUA and UAC can't protect against idiocy). On both Unix and Windows, the DAC's (Discretionary Access Controls) are really more about preventing accidents and malicious files from wreaking havoc without user interaction. However, even with DAC, if a user owned program becomes compromised (say via a remote attack) then the compromised program will have access to all other programs/object/processes with the same set of permissions.

Another thing typical on Unix machines is that scripts and binaries are not automatically executable -- one has to intentionally make them so (chmod u+x script). So, essentially, this is "SRP" out of the box. Furthermore, if one wanted to, one could simply make their entire /home partition non-executable.

These protections are primarily the reason you often hear that Unix/Linux is less vulnerable to malware and viruses. It's good to see that MS has finally taken these sorts of security measures seriously. These protections are far and away more effective than buying all this worthless AV software.

Then you have the whole topic of Vista's Mandatory Integrity Control model and how it ties in with SRP. SRP seems to me to fall in the realm of DAC while Vista's MIC is attempting to provide Windows with something like SELinux or Trusted Solaris Extensions (though less robust than either). MIC seems to be derived from the Biba model (Integrity Controls), while SELinux tends to be derived more from the Bell-LaPadula model (Mandatory Access Controls). But this is a whole other discussion.

Basically, what I am saying is MS has virtually copied what has been going on in the Unix world for many years. This is why I said that few "Windows" security experts were talking about SRP 10 years ago. That's because the concept didn't exist on Windows prior to the NT kernel. It has been around on Unix for at least 30 years.

This is why I always have to shake my head when I see so-called security experts claiming they don't need no stinkin' LUA or UAC. They are still living back in the Windows 98 days (before Windows became multi-user).

 

Wow. You got some knowledge stored up there!

I wonder though, why you would say the above statement. I mean, yes I understand. But for someone who actually knows thier OS (maybe not an expert ), it is really not a big deal to run without LUA or UAC. It is not those mechanisms themselves that save the bacon usually anyway, but your amount of knowledge. Giving the advice to not use those and just be an admin to an average user, umm, I don't know that it would be so great of an outcome. But then, I suppose it is those who are the ones with compromised machines and would not even know it.

Pretty fascinating read Chronomatic. Things like that make me wish sometimes I had hopped to *nix years ago. Alas, I find it more productive to use what those I support use.

Sul.

 

Even in the Win98 days, the value of default-deny and whitelisting was known, albeit the available MS tools for implementing the policy left a lot to be desired. Instead of SRP tools, it was the policy editor. The policy editor had a primitive whitelisting feature. Weak as it was, it was still able to prevent a lot of infections and unwanted software installs. The 98 policy editor had the same problem that software restriction policies do. It restricted the user, and for that it wasn't often used. FYI, the policy editor was capable of making separately tailored policies for each user.

Whether it's enforced by LUA and SRP, process firewalls like SSM, policy editors, etc, the problem always comes back to user acceptance. IMO, the only way the average user will accept running in a restricted mode is if they have no choice. As long as users have the mentality that a PC is more of a toy than a tool, I don't see that changing.

 

@chronomatic

In my quote above which you reference, I use the terms,

execution prevention/white listing/default-deny ​

That is: by default, any executable not already installed cannot run.

I avoided HIPS and the other terms which, I agree with you, have become whatever one wants them to be.

My point of the first post was to show that people were using 3rd-party execution prevention solutions to compensate for the weaknesses in Windows before Software Restriction Policies were developed.

It became evident to me early on that homes using Windows on the family computer required adding a default-deny security program to prevent unauthorized executables from running.

When SRP came out, I personally felt that it was more complicated to set up for the average user, so I stuck with a simple set-and-forget product. Besides, SRP requires XP-PRO, which most home users do not have.

None-the-less, a user with SRP who has tested many exploits with me has shown SRP to be effective in stopping all remote code execution attacks.

A good example:

DNS changer Trojan for Mac (!) in the wild
http://isc.sans.org/diary.html?storyid=3595

Malware researchers are beginning to emphasize that this is more of a threat than the remote code execution attacks.

http://www.gss.co.uk/news/article/5...pread,_says_researcher/?highlight=Trend Micro

In a recent visit to a local shop, I asked how the "cleanup" business was going. "99% of problems are operator error," was the response.

As long as this is the major problem, it matters not what operating system the victim uses.

----
rich

 

IMO, the better you know your system, the more aware you become of the damage that can be done from an administrator mode. Also, the better you understand the software needs of the user, the more you can "tune" that user account to their needs and eliminate the need to run as an administrator. It's not just the user that's running in a non-admin mode. Their software does too. If one accepts the fact that all software is vulnerable and can potentially be exploited, forcing that software to run in a user mode can make the difference between a compromised application and a compromised OS. Running in a user mode also acknowledges that you can make a mistake, a bad decision, a poorly aimed mouse click, another user.

My primary PC is multi-boot, 2 versions of Linux, Win2K, and 98. Most of the time I'm running 98, secured by the same 3 apps. On both 2K and 98, the first thing I do to secure it is to create separate administrator and user modes with SSM. On both, I run in user mode, which is strictly enforced default-deny. The only time I'm in administrator mode is when I'm installing, updating, or changing settings.

 

I am not trying to start a *nix vs. Windows flame war, but rather am just trying to get across that more Windows users should look beyond the old paradigm of "buy this security program as a fix-all for your security needs." Don't fall for that. Just about all of your security needs are now built into the newest versions of Windows. Take advantage of the LUA's. Take advantage of SRP. Look into and read about the mandatory integrity controls (which essentially lock processes down beyond what a LUA can. Remember, a LUA is an aspect of the DAC model which has inherent weaknesses on both Unix and Windows).

Remember, it's all about the principle of least privilege. All software has bugs (it's just the way it is) and some of those bugs will be exploitable. So, I ask: What is the better security model to mitigate this?

1) Waiting for some AV company to update their "signatures" after the attack has already been in the wild, and hoping they have caught all malware out there (highly unlikely). Only to lather, rinse and repeat.

2) Configure directories and files as read only, which will stop execution of malware all together (LUA and SRP) and configure vulnerable programs so that even if they are exploited, they can't do any damage to the rest of the system files (Access controls).

The decision is easy if you ask me. If more people would utilize these attributes built into the OS, there would be no need for about half of the sub-forums here at Wilder's (anti-virus software, anti-spyware, ESET, NOD, etc.. etc..).

 

I entirely agree with you. But, only to a certain point.

Yes, Windows users should make use of LUA. This, as you well say makes all the difference.

Now, about SRP. Well, I'm sure you're aware that Microsoft doesn't give easy access to apply SRP in Windows Home versions. Registry needs to be hacked.

Besides, even if GPO was given in Windows Home versions, more than 96% of users wouldn't know what the heck to do.

That's the whole problem - users not knowing what to do, and what's available to them. (This could be easily took care if the folks where people buy their systems explained to them, but by the end of the day is all a business, and they hope those clients will get infected and get back there and pay more to clean their systems. I'm not saying all are like that, because they aren't, but its a general scenario.)

So, those users need someone to apply them for them. I did it for my family members. I've set SRP to block any executable/other files from being run outside C:\Program Files\ and C:\Windows, with the exception of an exclusion folder where they can install software (not all require administrator privileges to install, nor require an install), run certain files, etc. Their daily tasks are not crippled by SRP.

Saying that LUA and SRP will cripple their daily tasks is a myth, and a decieving one. It won't cripple them in any way. It will just prevent, to maximum possible, any malware that could be trying to do it's thing.

Of course, both LUA and SRP are easily beaten if the user installs pretty much everything, or watches pretty much every e-mail received with those funny e-mails, images etc. But, then, it's something that should lay on their consciences. They need to be aware of their actions, and that it could hurt them seriously.

For example, my family members have Sandboxie installed, and I've forced their e-mail client to automatically start sanboxed, and I've applied extra restrictions there.
But, it's that way, because I did it, and not because they would know how to do it in the first place.

So, using LUA, SRP, DEP and UAC, it all comes down if users are aware such exists, and what they can do with them.

For example, one of my family members was running a laptop with Windows Vista Home Premium, in administrator account (The default account, which is stupid, if you ask me.) and with UAC disabled. It came like that from the shop it was bought. Why? Maybe because of the reason I mentioned before - business, means more money to clean the infected system.

Again, I agree with you. But, only to a certain point, and for the reasons I mentioned above.

So, I ask you: What's better for those users? Not having any anti-malware?

Now, is easy to say what could be implemented, when we know about it and what to do with it. Not so easy, when we have no idea about it nor when we don't know what to do with it.

Still, if users, and now I'm talking about my family, needs to install something, and they need to be sure its from safe sources, there's still the chance that software application has been tampered. It won't be LUA, SRP (and UAC) that will let them know about it. An anti-malware application would do all the difference, because it could detect something.


Cheers

 

This is an excellent thread. I work in IT and old habits and beliefs die hard. Users are afraid to step out of their comfort zones. Many of our users have either XP Pro or Vista Business or above at home (rare I know), but will not accept change in methods or thinking. To them, security = admin user accounts and third-party antivirus programs. That's it. All I hear is, "What anti-virus program is the best out there?" over and over again. And then, mentioning LUA? SRP? ACL?....to them? I might as well tell them the tooth-fairy is their best defense against tooth decay. Their attitude is, "Well since I've never heard of it, it can't be good." "Imagine, windows protecting windows, where did this guy go to school?" "What an idiot." Ironically enough, I've received the most hardened resistance from people with graduate degrees, but the most support from average people who seem to be more open to a change in thinking and methods. It looks like marketing, media and conformity still condition our minds.

EDIT: I just want to add that the best anti-virus in the world is the USER!

 

This is a good point, but frankly, I don't value signature based anti-malwares highly even for this role (to confirm whether a file from a "trusted source" really is trustworthy or infected with something bad).

The problem is as usual psychological: For every time that I have seen an anti-malware product catch a real malware in a file that came from an actually trustworthy source (well-known, legit software authors and their official websites like microsoft.com for example) I have seen at least a hundred cases where an anti-malware product has a false positive and falsely detects nonexistent malware in perfectly clean files. This is great for making the user distrust the anti-malware and teaching them that most detections will be false positives anyway.

So, as I see it, if the user downloads something from a source considered trustworthy, and the anti-malware claims that it's infected, there's a really good chance that the user will just brush that off as yet another false positive, based on previous and perfectly valid experience, and install anyway. In the end, the anti-malware product wouldn't necessarily make any difference. I'm sure that sometimes it might be a life-saver, though, but that is the exception rather than the rule. I have seen "targeted" email attacks where the email containing the malware as an attachment actually tells the receiver that the attachment will cause antiviruses to cry wolf and claim the file is infected and that the user should just disregard that since the file is actually safe and the AV just giving a false positive.

Really, the largest security weakness that I can see is the unwise user. And the world is just full of them. I have seen people with all kinds of anti-malwares and sandboxes and HIPS running at the same time just happily turn all of that off just so they can run the crackz they just downloaded - and bam, a Virut infection or any other badware du jour. SRP and such can protect against remote code execution, but nothing can protect against an unwise user.

 

And I've always felt that the remote code execution exploit is the easier of the two problems to defend against!

The unwise user hopes that some scanner will protect against dubious downloads. The numbers of people frequenting the hijack forums shows that this is not reliable.

Now, the remote code execution exploits get the most press, because of the sensational aspect of these attacks. Yet, by some accounts, this type is not the largest category. I've quoted this before, but to re-emphasize:

TrendMicro for 2008:

http://www.gss.co.uk/news/article/5...pread,_says_researcher/?highlight=Trend Micro

I wouldn't have thought the spread to be that much, but even if less, it indicates where the real threat is!

As has been pointed out, running in a User account and having SRP and other protection is no help when the user grants installation privileges. I've also quoted this before, but it is typical:

DNS changer Trojan for Mac (!) in the wild
http://isc.sans.org/diary.html?storyid=3595

----
rich

 

Exactly right. It's easy to deal with code, but difficult to deal with humans! And really, when was the last time anyone saw a HijackThis log that didn't have some kind of an anti-virus product present? They just don't do a good enough job to protect a system, and can create a false sense of security ("I have an AV, I'll be okay").

Educating the user is the real challenge. In my experience, piling endless amounts of anti-malware scanners on a system doesn't really teach the novice anything about security. Forcing them to deal with something like LUA will help a little, and can be a step towards actual understanding. Of course, it's easier said than done to make people take limits on themselves, whether that be limited accounts in Windows or seat belts in cars.

 

Isn't that the truth!

Educating the user is talked about a lot, but there doesn't seem to be a magic formula.

Years ago a Gateway store offered a free 1-hour tutorial when you purchased a system. It was very basic - learning how to turn on the computer, create directories (folders now!) I remember the description of the topics covered included care with email. I applauded them for doing something, although it's obvious that 1 hour is just a beginning!

This was back in Win9x days and the complexity of the operating systems has grown tremendously. I learned early that the best "education" is hands-on, sitting next to the user, getting to know the user's knowledge, computing habits,and so forth.

I've come to realize how difficult it is at a distance - on the forums, if you will. A good example is Software Restriction Policies. When I first read about them, I thought, this is a real answer for many problems in home situations that appear on the forums, and I highly recommended their implementation. Until the "how to" threads by tlu, Sully, Lucy came along!

First, since most home users probably don't have WinXP Pro (I do not), implementation is problematical without lots of tweaking.

Second, and more important: I began to realize that it takes much more knowledge than most home users probably have. And the time involved! So, this might be the reason why Microsoft didn't include SRP with the home edition of WinXP.

That was a good lesson for me.

I don't work with users as much as I used to, but my experiences proved to me that if you can show first hand how to set up secure policies with email, downloading from trusted sources, browser configuration, and the like, you create a safe computing experience with very few security products. Basic computer security is much simpler than it is made out to be. But you need time to cover the many basics!

Most of my work was with families, often just one computer in the home. I never would work with someone who downloaded from pirate or crack sites, and the like. I always asked that right away!

With the exponential growth of digital technology (mobile phones get viruses!), the social networking sites, etc, user education is a huge problem since the topics and scenarios to cover have multiplied immensely.

Malware people know this, and they know that the general population has very little knowledge of exploits, and more than likely depend on the Anti-Virus product that came with the computer. I'll guess that malware people could care less about the small minority that use sophisticated products that are discussed on the forums. Why should they when old unpatched Internet Explorer exploits are still successful?! And polymorphic trojans fool all but a very few AV products - that was reason for the huge success of the Storm malware, for example.

So, "user education" has become a phrase, almost a cliche, and it has really no meaning. To advise to use a User account, or configure Software Restriction Policies results in a big Huh? from the ignorant.

I don't use that word in a demeaning way, just stating a fact: the general population has no idea what you are talking about because they haven't been exposed to anything more than what the salesperson told them, and so upon setting up their first computer, probably are more concerned with why you click Start when you want to Stop the computer.

I used to say, Adopt a user. I still think that is the most effective approach to user education. Assuming the person will listen!

----
rich

 

Very well said, and I agree.

In another thread here, there was someone who wondered why Microsoft didn't make things like running as LUA and using SRP more easy, so that more people could use them. My answer was that they don't do it because it's almost impossible to make a system like that both secure and so easy to use that even the novices can understand it, especially when the system also has to be so unintrusive it doesn't annoy people (and most people are easily annoyed). The solution, I think, is not making these things easier, but making users smarter. Otherwise, they will just walk around and click through even the easiest-to-use security system possible. So it all comes around to educating the user. You can patch vulnerabilities in code, run security software that attempts to stop people from doing things that might cause harm (delete C:\Windows, how about no?), but in the end, there will always be the Problem Exists Between Keyboard And Chair issue that must be corrected if the system is to be really secure.

I fully agree about the "hands-on" approach to educating users - it seems to be the most effective. It has many benefits. For one, people are less willing to argue or discard the advice of someone sitting next to them, but quick to forget what they heard in a forum from some faceless person. That has a surprisingly large effect at times.

Nowadays, the first thing I tell people is that if they want to increase security, they have to accept some limits upon themselves as well. If they do not accept this, then the whole thing is doomed to failure because the user just doesn't have the right mindset. I tend to use one of those silly car analogies (people seem to understand those): "If you want to be a safe driver and get home to your family in one piece, it's not enough to buy a big car with fancy tech to save you. You have to keep your eyes open, you have to avoid driving faster than the road conditions allow, you have to be sharp instead of driving drunk or dead tired - you might want to put the pedal to the medal to see how fast the car goes, but you shouldn't do that, unless you're on a race track. It's exactly the same with computers, except crashing a computer won't kill you. Getting it infected with something may, however, take your credit card info or use your computer as a server for child porn. So you have to 'drive safely' and carefully consider your actions before you do anything. Sure, this will limit what you can do quickly a little. So will a seat belt. But a seat belt might save your life if something happens. A limited user account is a lot like that. It will cause some extra work for you sometimes (two clicks instead of one, or having to log out and log in as admin to do something), but that extra work is nothing compared to the pain of having to close down credit cards or having to explain to the cops why your computer is hosting highly illegal material."

An amazingly large number of users, even the ones interested in security (or more accurately perhaps, interested in playing around with security software), are not willing to limit themselves even a little, even if the limit is simple as a LUA and sometimes having to log in as admin to do something, taking all of five seconds of your life maybe. I've even heard someone claiming that running as non-admin is cowardly. What can you say to stupidity like that?

And here I think is a good place to mention Linux. People should really take a long hard look at what Linux users in general are doing: 1) They run as non-admin as a rule, always. 2) They make an effort to actually understand the system they are running, and learn about it. 3) They think before giving root access to something random asking for it.
It doesn't take much more than that. Linux isn't a magical operating system. Linux users don't get infected often because Linux users use their heads. If Linux users can accept the "pain" of running as non-admin, can't at least the more advanced Windows users also grow a pair and just do it, and lead by example?

Adopt a user, as you say... Lead by example... If we just tell users to "run this AV, and this AT, and this HIPS, and this firewall", we're doing them a disservice, and planting on them the false mindset that security is a bunch of programs.

SRP and similar tools require understanding. A good way to build some of that is to just read. Microsoft has made enormous piles of documentation for SRP, and even the policy editor in Windows has a help file that will teach you how SRP works. People just never RTFM. If I got a penny for every time someone asks a question that is answered in the help files that come with Windows, I would be the richest man in the universe.

SRP is an excellent solution for admins, or just advanced home users, but it was never meant to be for novices, and it cannot ever be for novices, because the very concept of restricting what programs can run requires a level of understanding from the user that far surpasses the interests of John Doe, unless someone spends a lot of time on teaching him. Personally, I think HIPS and sandboxing software are even less for novices than SRP, because they tend to ask a whole lot of questions from the user - questions which the user doesn't understand at all. "Allow this dll to be loaded by this process? What the blazes is a dll and what is a process, and why does a dll want to load... or was it the other way around? I better click cancel. Hey, why doesn't my printer work anymore?" This will never work unless the user is educated enough.

Well now, that was a bit of a rant from me, but I had to let it out.

 

Hi everybody,

I was away for quite a ong time and happy to be back,especially with all the good threads abour security in general and lua+srp in particular.

I would just want to react to this sentence:

Microsoft is really trying to take the Unix path for security, while keeping as much as possible the ease of use. The perfect system would be a M$'s system with the security of Unix, wouldn't it?

UAC was a perfect step ahead, to introduce the habit of lua in some way. Nowadays, contrary to a strong live belief, running lua is so easy, as it requires only a right click + password to run an install. Of course it is not idiot proof, but rather people could understand with time (it could be few years) that admin is absolutely not required, the extreme majority of time.

In this model, SRP is just a small step ahead between UAC, default ask, and SRP, default deny. In both cases, you have to input your credentials to go further, but at least with SRP, you don't have a "ask" question when a malware wants to install, but rather a deny. It is transparent, and user will use the credential only for a desired install. Once again, not an idiot-proof...

 

And that's what happens in most infections scenarios - people installing something they shouldn't.

Of course, in such situations, no SRP, no nothing will be of any good. This is more than beaten.

The problem again is, people believe that they really need, for example, to download that "codec" to view a video, or even listen to a music. Or, to download "Adobe Flash Player" to view flash contents.

Why do they believe in such? Because they don't know otherwise. Nobody tells them.

I see security vendors writing white papers, etc., but do they really give alerts to their users into their systems? A simple tip of the day reminding them to not to install codecs, etc., because they simply may not be.... And if they do need, then to get them at the official sources by going themselves there and not through some link given in the site they're at.

Do security vendors do this? No, they don't. Why? Well, people wouldn't become infected, because now they would know how to protect themselves in that matter.

I've alerted my family members for this sort of situation, where they might go to a web site, that seems normal, or even getting an e-mail, which could come from a known contact whose account could have been hacked (it happened some time ago with a family member's friend), that if they get some message saying they need a codec, etc., they won't, because the system already has more than enough codecs, flash installed, etc.

But, all other people that don't know and have no one to tell them about it, well... they're believers... and they believe that they're just going to see a funny video.

Security vendors have no reasons to alert users for this. It would be the very begininning of their end.

Then, we have other folks that simply keep on installing pirated software, games, and ask what's the best protection out there... Well, there's no protection for them, at all. Unless, they run this pirated software and games in separate machine without any contact with the outer world, and the users keep it's use for themselves, and won't share anything with anyone else.

It was like the all hype behind Conficker... It seems that every year some major threat comes out and security vendors play an advertising game... Conficker will harm you, get our protection.... Did they actually tell the users how they could protect themselves, without having to pay for their products? No, sir.

This is all a business for the security vendors, and the more stupid computer users out there, the better. Means more money for them.

People need to be instructed... Just the same way there are people that, in the real world, fall for crimes (like cons), need to be educated about them. It doesn't matter if they've got a bulldozer, land mines, pitbulls, etc... They'll still fall I they have no idea on how to prevent being coned.

 

When Microsoft started developing Windows NT, they certainly had a Unix-like (more "any multi-user OS" -like) security model that they wanted to build, and then did. Contrary to what some people have falsely claimed, Windows NT is a true multi-user OS if there ever was one, and it is built from the ground up for security. The only problem was, they chose the wrong defaults - when the user is admin by default, there's going to be a Windows 9x -like result, that is to say trouble. As new versions of NT have come out, Microsoft has constantly tightened up things, slowly but surely, having obviously seen that they screwed up with the default admin thing. The default file permissions were tightened up with each release (for example, Win2k gave Everyone Full Control permissions on the system drive root folder, but XP changed this to Everyone Read & Execute, no longer allowing everyone to create files in the root of C), and features like the Windows Firewall and SRP were added. And then of course there is UAC...

To me, running as non-admin has always been an easy thing. Installing software never took anything more than a right click on the installer and a Run As. This was before UAC, much before. In that sense, I don't really see that UAC has made using non-admin much easier. Instead, it's somewhat made admins non-admins, annoying those few who have a legitimate need to run as admin for longer periods of time, and still not providing the security of a limited account as long as the user is logged in as an admin even with UAC enabled. I think, instead of making a pop-up thrower like UAC, MS might have done better just making a brutal solution and creating true limited user accounts by default, instead of the UAC-enabled admin accounts it now defaults to. But that is my personal opinion... I don't think UAC is as good as Microsoft claims it is, or as bad as some people say it is. Unlike SRP, UAC is not meant to be a security solution as such (according to Microsoft, that is), and I wouldn't really put them on the same table. SRP is designed to increase security by letting admins decide what programs can run, and it has no other purpose. UAC was designed to enable admins to be non-admins most of the time, and although that does add security, it isn't really the primary purpose. To me, it seems to be some kind of a demo: "Look, it's not that hard to be non-admin."

Problem is, people are illogical. The same guys who run ten security softwares on their system, with all kinds of behavior blockers and what not, will complain loudly when someone says they're supposed to run LUA: "But it's such a pain!" And yet they fail to see that what they are already doing is much more of a pain, and indeed makes the system much more unstable than anything Microsoft has ever managed to screw up will.

One thing is sure. It's not easy being Microsoft! Anyway, it is good to see discussion about SRP for a change, rather than the anti-malware du jour.