I can see how this would protect a machine from becoming a bot or from being adware infested, but I don't see any real time protection. It's proactive in that malicious code won't become permanent but doesn't stop it from running in real time. I'd view it as a good 2nd layer but insufficient as a primary defense.
There really is no such thing as a single, primary defense as all single solutions have their own specific weakness. This is why a layered strategy is essential where each component should be placed to cover the weaknesses in the other components parts of the overall strategy. The time protection comes in where the gaps in solutions like AV/AM/AS become problematic. This is where unknown malware/PUP content is concerned. Think of the situation presented by Stuxnet, flame, and the older Rustock where they went undetected over very long periods of time which in turn allowed that content to do what it was going to do for that same period of time. With ISR in your strategy, you narrow the time where that content is active to the current boot session with it being removed at the very next reboot of the computer rather than persisting over weeks, months, and even years in some cases. The weakness of ISR is that it is not designed to scan/detect for malicious/suspicious content. This is where you need a canary in the form of an AV/AM/AS solution or a more minimalist approach where you actively block content from executing (ref: AE, whitelisting, etc). the latter is most effective in expert hands that have the experience to create proper rule sets but has the weakness of irrelevancy in novice and/or inexperienced hands that create improper rules or simply get frustrated and bypass their own security.
It seems that the biggest difference between what each of us is describing is how we view and define the terms. I've often referred to the combination of SSM, Kerio 2.1.5, and Proxomitron as the core of my security package. I don't consider each application as a separate layer. I regard the three plus the configuration of the operating system and applications as my primary defense. The secondary layer includes file integrity checking, folder content monitoring, and the batch files that wipe specific folders and replace my registry and core system files on reboot. For all purposes, there's no real distinction between what I call the primary and secondary layers, save for their policy defined roles. Both Kerio and Proxomitron are configured to enforce default-deny policies, yet both will alert to unwanted content or attempts at unwanted connections. The different components are also configured to monitor and protect each other. SSM protects Kerio from termination and influence from other processes and will restart it if it crashes or is terminated. The integrity monitor protects the rulesets for all of the core security apps. Kerio forces browser traffic through Proxomitron. If Proxomitron crashes or is killed, the browser loses internet access. The real layering is in each applications ability to protect and support the others, making it very difficult to compromise or disable any single component. The individual applications themselves don't secure a system. It's the policy that the combined package enforces that protects it. No individual component or application is any more important than another. Each is important for the specific role it fills. Integrating the components to support each other and establishing/automating procedures regarding both everyday and administrative roles is the attention to detail that makes it work. This is why I feel that users should start with choosing a core security policy that matches their needs and skills, then select and configure the components that can best enforce it. In the end, they get a system that's matched to them and their needs, not one that they have to adapt to.
I think we are arguing the same thing, just with different approaches; namely a multifaceted strategy to address and mitigate risk.
The knowledge & discretion of the end user. Using the former to greatly reduce the attack surface and potential for vulnerability in the first place before applying the things on your list. And the latter so that it renders the stuff you use almost entirely moot anyhow.
Which is easy to manipulate. IMO the users have to be stripped off of their rights and OS developers should create locked down systems, so no matter how much the user messed things up, the damage will stay minimal.
And the latter so that it renders the stuff you use almost entirely moot anyhow. I've seen that argument a few times here, something to the effect of "Those who know how to configure a classic HIPS are the ones that don't need them." It doesn't hold true. The user isn't always given a choice. If an app is exploited to download and execute malicious content, the HIPS provides the means to deny the execution. IMO, reducing and isolating the attack surface should be part of all security policies. The HIPS and other security measures protect the portions of the attack surface that can't be eliminated. HIPS are not a substitute for limited accounts, reduced permissions, etc. Those are configuration choices that a good HIPS can complement and enhance. A good classic HIPS can do many of the same functions that limited accounts, SRPs, and permission restrictions do, but use different methods to accomplish it. As long as the user isn't trying to restrict the HIPS itself, they complement the built in security features.
I actually agree with pretty much everything you say. I personally use both a classic HIPS & policy restriction, and don't consider one a substitute for the other. I think the impasse here is that I don't think what I said and the concept you're referring to are the same thing at all. At least I didn't intend for it to mean that. But the main gist about the knowledge of the end user, and their safe habits trumps whatever other measures they take... even dictates it, in fact. And because of that everything else on that list boils down to those two things in the end. A person will use both HIPS along with SRP/other privilege/policy restriction, sandboxing & virtualization, imaging, isolation (vastly under-rated IMO, and not fully understood/implemented... for me it starts with creating dedicated partitions for certain apps, namely your browser(s)), outbound FW's with tight/granular rule sets... they will do all of this because they're informed. And then they will use NoScript and take the time to whitelist or temp. allow things one by one to learn what they need & don't need... and not just go clicking on any random link they see because of the discretion part. I'm not saying those two things render the rest useless, or that you can even be lax about it. In fact I'm saying people that utilize those 2 things will probably be using that stuff because they know of the benefits of doing so, and how to deploy it. And as such all the things on that list boil down to those 2 things. This was not a: "I'm a safe user and therefore don't need to deploy any security measures" type thing at all. Though I've also seen it in here very often so I can understand why you may have been a bit presumptuous. But if you were familiar with my username and the usual content of my postings/rants you'd have realized I don't look at things that way. Especially if you've ever seen me really break down my security setup in that gigantic thread asking people to do so. I would hardly go to those lengths if I felt that my safe habits alone were enough to keep me out of trouble.
Windows was always about making their OS so that (out of the box) usability and compatibility were the main focuses. Which subsequently made them, out of the box, a security nightmare as well. But at least they left techy/geek end users the ability to tweak & trim the OS and close up and/or eliminate the stuff they didn't need, and in the process close up associated vulnerabilities and bloat. In fact left us with the ability to pretty much go through everything with a fine tooth comb and make it exactly what we wanted it to be, if we took the time to learn exactly what we did and didn't need/want. This made it easy to break things. Which is why only people that really knew what they were doing should attempt it. And also why wholesale changes are not a good idea (1 thing at a time), along with clean images. But once/if you got things all tweaked & trimmed down, along with the implementation of good 3'rd party support, you'd be left with an OS that is very secure, still very usable/compatible for what you needed it to be with, and much more responsive. I'm talking namely about Windows XP, and versions prior. Since then they've taken away the ability for people to go through things with as fine a comb... by design. Whether it was to make it so that people couldn't break things as easily (for the sake of John & Jane Q average user), or to intentionally limit people's ability to really lock things down, limit attack surface, and peek behind the veil of the OS to see what's really there... is all a debate for another time & place. It's more secure out of the box, based on what you can see, and if you trust what you can't see/tweak/trim. I feel safer with the former scenario personally, especially from a privacy standpoint. If they would release a Windows OS that had the same level of customization/control that XP and it's predecessors had, the same feel, along with solely marked, undeniable improvements made since, for example to the kernel and mitigation techniques (without needing to take on the bloat & vulnerable framework to use it in the process known as .NET)... then I'd sign up in blood for it. But unfortunately I believe that their end game isn't about giving their customer base what is truly in their best interest, but rather about the best interest of another group, called elitists. A lot has changed since XP was being developed.
@luciddream I did misinterpret your statement. Like you said, arguments like that have been repeatedly posted. As for who posted them, where they are at or their exact wording, those are the things I can never remember. Sorry for being presumptuous Regarding safe users and good habits, that doesn't protect a user nearly as much as it used to. With good sites being compromised, malicious code sneaking in through the ads, attacks on PCs, routers, and the DNS system itself redirecting users, there are no safe or trustworthy sites. I don't go looking for problems, save for attempting to capture the occasional exploit or malware. On todays internet I expect trouble to find me, whether I want it or not. I agree with your assessment of the newer operating systems versus XP and earlier. IMO, "to intentionally limit people's ability to really lock things down, limit attack surface, and peek behind the veil of the OS to see what's really there..." is exactly what is going on. Their built in security always seems to have exemptions or bypasses touted as features. It's like they copied the idea of HIPS but weakened its enforcement abilities and restricted its abilities at a service level. I also believe that the new versions of Windows are designed to give control to someone else. The insane level of rhetoric and scare tactics they've employed against XP, just as they did with 98 only convinces me more. For users who distrust where modern computing is going, the single most important aspect of a security setup is an OS that the user can control, not one that controls them.
Having fun dissing newer modern version of Windows and then claiming how secure the older versions can be made... Overconfidence in "default-deny" as primary defense while previously calling out DEP, ASLR and such as "alphabet soup". Ya right...somehow forgot to include SSM in the list? Trimming attack surface? Holy ****...your beloved OS has no basic address space memory protection. Your kernel is flawed as hell but all that doesn't seem to matter as long as "default-deny" package is in the house. Some people found the magic cure for security issues. They are a class above the rest of us mortal beings and are smarter than those in the security field. Let's all go back to Win98 era. Big time LOL.
And yet I've gotten by just fine all this time with those flaws. My kernel must be doing something right. Perhaps eliminating so much of that surface helped me in this regard... something you can't do on your shiny new toys... which by the way are diming you out about every click or keystroke you ever make in your life. And harvesting all your info. to Google & Big Brother like it's a wholesale operation. Assume you are backdoored... because you most definitely are. But hey, at least you have those shiny new mitigation techniques and an uber awesomness kernel (I'll just assume it's much better than mine since it's so often brought up that it's newer and better than mine). Funny though how I don't ever hear any specifics. Or examples of my current kernel leaving me down or being inadequate either. This reminds me of the Firefox 29 Shiny New Things video on Youtube. Just substitute Windows 7/8 for Firefox.
I voted other. The most important part of my security setup is imaging and the associated separation of OS and Data. It allows me to recover from my own mistakes which are far more likely to happen to me than malware. Whether it from the outside or my own poor judgment at a given moment, if something goes wrong, In 10 minutes I can restore the OS, be up and running as before and I have separate backups of my important data. For the rest, I use software that is minimal and effective and LUAs. I try to use the resources of the OS, whatever OS I'm using, as much as possible rather than install bloated security suites. File permissions can do nice things for security and come with the OS.
Other: Browser. In checking web sites with in-the-wild exploits over many years (from Malware Domain Lists and other sources), I've never found one to work when Plug-ins and Javascript are whitelisted. [I assume your question assumes that "most important" doesn't mean "only." I also assume that your question is directed at individual user experiences, and not asking for suggestions for a security setup for anyone else.] ---- rich
Policy Based, predicated upon the O/S, as it's the operating system where I feel security needs to be the primary focus.
Well I've stated how I think everything mentioned above boils down to end user know-how & discretion. But being more specific, my choice would be eliminating as much attack surface as possible on the OS you use. Not only do I trim down services to only those needed (I have only 9 enabled), and LP/GP/SRP, etc... tweaks, and tons of other things. I also don't use any of the most commonly exploited things, like .NET FW, Flash, Java, PDF progs, Have no plugins installed in Firefox (only extensions). Do these things and the 3'rd party security on that list can be rendered rather moot. Honestly, I could probably get by just fine without any of the stuff in my sig. Just my hardening and a router. But it makes me feel better knowing it's there.
@luciddream I'm sorry to say this but if you think you are fine, it is because you have blindfolded yourself to the obvious. I'm not going to spoonfeed you with links because I have done so in the past. I think my effort has for the most part gone to waste. Do yourself a favor....learn what those mitigations you belittle/dismiss and find out their importance in the overall scheme. If not, this debate is rather pointless. And nope, this isn't about whose toy is newer or shinier. I've stopped playing with toys...I suggest you do the same.
I do know that in my almost 10 years on XP I've never needed any of those mitigations to successfully operate a clean machine. I did see (software) DEP once spring into action and close out an app due to what it thought was a buffer overrun, but that session was sandboxed anyway... it was the thought that counted though. I can only guess that some of you engage in far more dangerous surfing habits than I do (porn perhaps?), because you're coming at it from an angle that anything that theoretically "could" happen... expect it to happen. Only in the real world none of that stuff has ever happened to me in said 10 years or so. I will gladly, even eagerly welcome those mitigation techniques when I don't have to take on a gigantic, bloated chunk of attack surface in the process (not mentioning any names but it's initials are .NET)... I feel that the two combined/required measures would actually lessen my security in the process, and not enhance it. Since another large part of what makes XP more secure/private/etc... right now is a much smaller attack surface, and also being far less targeted... contrary to all the stories of millions of botnets waiting to PWN XP users post EOL, the truth is, as always, OS's being currently developed are the ones in the crosshairs. Well before XP's EOL came you could see it... far less critical patches required for XP. Usually just 1-3. To the point I'd just let 2 months pass to bother doing it because 2 patches (that don't affect me) just isn't worth my time. Then I'd go work on a friends machine running 8 and see like 35 criticals.
Once again, your emphasis is all wrong. Quality of code matters much more than quantity. Your attack surface is not as small as you believe. To the contrary, it is wide open because an attacker can reliably predict target addresses...no need for information leak whatsoever. I'm honestly trying to help point out where you might have been misled into thinking that lesser code means more secure. But if it offends you, feel free to believe whatever you want and keep repeating how secure & private you feel if it makes you happy.
