This blog is only an introduction-level for this topic but even as an introduction I think there is much you might want to digest. More detailed write-ups of this functionality may be seen in future.
Access Protection is being replaced by new tech, called Arbitrary Access Control (AAC), which is introduced through our core driver technology SYSCore version 15.3.0 and later.
Over time, more Intel Security products will release with this technology included and they'll use it to protect their own files, registry, etc.
Products that are new to this regime of protecting their files/folders and registry etc, may not have the same scope of functionality available that you're used to seeing with VirusScan Enterprise such as notification events.
Access Protection, as described in an earlier blog, is rudimentary in its purpose and design; it's super effective but with limitations. Well, those limitations are mostly imposed upon you, as in, we opted to _not_ expose its full potential to customers. And considering how some people have used what we did expose, and still manage to shoot themselves in the foot - figuratively turning their machines into bricks - it's no wonder we are cautious about unleashing this technology in all its glory. Maybe we could provide full capability to everyone but have it remain locked until the Admin takes and passes an Access Protection Driver's License Exam , or complete a mini-game that unlocks the "Behavior Blocking Badass" achievement. Hah. I kid, but I still think something like that is appropriate.
A companion concern that has to be assessed by us when entertaining the notion of exposing AP's full potential to customers is the Support cost associated with it, and today, I'm skeptical we have the infrastructure needed (or perhaps even the expertise at this time) to support the needs such exposure could generate. I'd feel better about it if, and perhaps only if, we incorporated the driver license idea or similar because that would ensure a level of proficiency on the Admin's part (I seriously doubt any Product Manager would suppose that a good idea; just let me chuckle to myself about it some more!)
Under-the-hood, we do take advantage of Access Protection's potential as needed. Some of our default AP rules are quite complex in their definition. And I think most everyone who has sought to use this feature has experienced the front-end limitations we've imposed, where only processes can be set as things to include or exclude, along with a singular "thing to protect". Under-the-hood we have rules defined to protect multiple objects; processes, files, folders, registry keys, ports etc, all in a single rule, and each object can be defined as having its own type of restriction (create, read, write, delete etc).
A problem we wanted to solve was to provide this type of protection for Intel Security products and to not have this dependency upon VSE. This was easily solved in concept. The technology VSE used to provide Access Protection functionality is and has always been a separate component of the product. We simply needed alternate means to distribute that technology into the field. It would become a common component of any/all Windows-based products, be it the Agent, Host Intrusion Prevention, VirusScan, whatever - every release would include that common technology (for installation/upgrade purposes) and the Product would simply convey to that technology what it wants protected. That common technology is called Arbitrary Access Control, or AAC - the name may change in future, who knows, but if you say AAC to someone from our side of the fence hopefully we'll know what it is you're referring to . AAC replaces Access Protection.
SYSCore 15.3.0.x (and later)
This common technology, AAC, exists in SYSCore version 15.3 and later. SYSCore is comprised of various mfe*.sys files, and mfevtps.exe (the validation trust protection service). It is the part of Intel Security software that melds with the brain of your device (kernel code). I've stated elsewhere that when this code changes in version it should be a signal to tell yourself, "We need to do some testing against this release before deploying it".
You might notice that newer software releases from Intel Security, products that in the past relied on VSE to protect their files/registry etc, are now providing their own protection coverage when only their application is installed. It's because they installed AAC and told it what to protect. That being the case, be forewarned that the risk associated with patching VSE should be viewed more generally now, since the newer SYSCore binaries could be accompanying other product releases too.
Some products that come to mind that have already begun to use SYSCore 15.3 (or later) are: McAfee Agent 5.0, TIE/DxL 1.01, VSE 8.8 Patch 5, HIPS 8.0 Patch 5, Stinger utility. And in saying that I should point out that these products may not install _all_ of SYSCore's components; they install only what they need, so it's feasible and OK to have a mixed bag of file versions for mfe*.sys files when using multiple Intel Security products. Where products do install the same SYSCore components, the highest version wins.
Another thing to add regarding SYSCore files: You cannot downgrade them; nor can we forcefully overwrite or downgrade them - to do so would result in a BSOD (worst case, continual BSODs); the brain surgery analogy comes to mind again. If any code path accesses the now missing area of code, the result is fatal. An operation could appear successful though, no instability, but it will then mess up internal reference counters that will cause future problems for you.
To be able to install an older version of these files you must remove all Intel Security products that share/use that technology, and then reinstall the desired version. Typically the notion of downgrading only comes up when a product or patch was installed that updated SYSCore, and an unexpected (serious) issue occurs - the desire is to back-pedal and try to reset the system to a known good state. This is understandable, just be mindful that for us to investigate whatever caused the outage we will need data and that might mean having to revisit the setup that failed. See my prior blog on Patching VSE for tips on preparing to adopt new code, because if you prepared well we will have something to work with.
Differences between Access Protection and AAC
As far as VirusScan is concerned, any difference should not be noticeable to you as the customer (unless of course you found a bug ), or to end users as shall be explained herewith. There are differences however...
For products that never provided their own protections before, it's absolutely a new thing that they now install SYSCore and define what objects of theirs are to be protected.
Rules are defined differently in AAC. But as I said earlier, from a customer-perspective there should be no observable difference. What happens under-the-hood though is quite different indeed.
- Access Protection used a simplistic syntax for defining rules which would be interpreted on the client when the rules were being loaded. The rules would be loaded from VSCAN.BOF (where our defaults exist), and the registry (where User-defined rules are stored, as well as any edited default rules which will overwrite those from VSCAN.BOF).
- AAC uses XML to describe the rules. Each rule is assigned a rule ID, and each product who creates rules is assigned an ID; allowing for a single product to have multiple rules, and for multiple products to share a single rule.
AAC is more powerful than Access Protection. It allows for securing more types of objects (this is only going to be leveraged internally of course) and with better control or flexibility, affording more intelligent rules to be defined. VSE probably won't be seeing any of that additional intelligence... the goal for VSE is to provide the same protection level with the newer technology. The future, however, could be quite exciting - I'm not sure what degrees of flexibility and control we're going to expose yet.
In the case of VSE, troubleshooting AAC issues can be done in much the same way as troubleshooting Access Protection issues -
- disabling the feature
- adding a process to exclude
- setting a rule to Report only
- disabling a specific rule(s), or even all rules but keeping the feature enabled
- renaming the driver (mfeaack.sys) and rebooting; this is a brutish troubleshooting step, and should only be done with acknowledgement of it being a test only. When used as a means of progressive elimination it can be telling of the nature of an issue.
- for in-depth view of the functionality, an internal tool (ETLTrace) is required, and must be version 15.3 or later. Support may request you to use this tool when investigating related issues.
- A non-supported EXE is included with SYSCore 15.3 called "AACINFO.exe" which Support will use to export the in-memory AAC rules (i.e.
aacinfo.exe query >aac_rules.xml). This tool cannot be used to configure AAC.
Security through Obscurity has limited value, but development teams may still implement protections after that manner. Example: As stated above, this is new technology and other products (like McAfee Agent 5.0) now install and use this technology to provide their own protections - well, VSE has an Event/Alert subsystem for processing events and sending the info to ePO and recording the violation to the local Event logs but MA does not, they only have local logging functionality (at the time of this posting - see KB82881). We can expect to see some growing pains as products adapt to AAC and recognize other supporting functionality that's needed. Providing visibility into when violations occur, what was blocked and when, is a good example.
That doesn't mean you should postpone an upgrade, it just means there may be another data point to consider when you're investigating a symptom that looks Access Protection-related but troubleshooting has revealed it's clearly not VSE's Access Protection that's involved.