Using File Monitoring to Limit Admin Rights

Over the past few weeks we have been posting blogs about the importance of limiting user account rights to only what is necessary for someone to do their job. Users should have all the rights necessary to do their job, but nothing less and certainly not any more. This includes local administrator rights. Only the people that absolutely need those rights should be given those rights. It is also our argument that fewer people actually need those rights that people generally believe. We’ve also posted a few times already on the dangers of giving people too many rights on a system. And remember, this applies to both Windows and Unix systems. Just because you can login as root, it doesn’t mean you should.

A question that comes up a lot though is, “What about software programs that require the user to be a local administrator in order to run the program?” Well, as I argued in a previous post, most programs don’t need the actual local administrator rights, they just need access to an object that the current user doesn’t have access too.

One of the most common objects that users often do not have the rights to are file system objects. Now in a perfect world, software developers would write their programs to only access portions of the file system that are accessible to everyday users. Or at a minimum, developers would document what file system objects they need to access to run their software. Of course reality says developers & documentation rarely go together. So how can a sysadmin figure this out for themselves?

In the old days, we could always use tools like Filemon & Regmon by Sysinternals to figure this out at a granular level. Unfortunately after Sysinternals was purchased by Microsoft, they combined the tools into one giant monitoring tool called Process Monitor. Don’t get me wrong, it’s a great tool and very capable of gathering system information. The trouble is it can be TOO powerful. Sometimes there are so many things happening on a system that it can be difficult to isolate just the file system events. So it would appear we need a different tool that we could use to monitor simply the file system object events to help us isolate where a user may need additional user permissions.

In searching for an app that would do this, I wanted something that would be isolated to file system objects, have the ability to start and stop monitoring on command, have the ability to reset logs, and have the ability to export data to a CSV or similar format so I could manipulate the data in Excel later if I needed to. Oh, and it would be nice if the tool were free. Even better would be if the app were a portable app that I could bring with me in my toolkit without having to install it on a machine. That’s when I found Moo0 File Monitor.

Let’s say I wanted to run Microsoft Word as my test case. I want to make sure I know all the file system objects that Word needs to access in order to run on my machine. To gather my data I would need to:

  1. Close all open programs running on my computer (for the cleanest results).
  2. Open Moo0 File Monitor and make sure it’s gathering data.
  3. Clear the Moo0 logs to get a blank slate.
  4. Open the program I want to test (such as Microsoft Word).
  5. Close the program I’m monitoring to see files accessed on program exit.
  6. Click the Stop button in Moo0 File Monitor to stop collecting data.
  7. Save the Log File for later analysis.

The results of this process should be a list of files that were accessed during my session working with the software program in question. In this case when I tested it with Microsoft Word I received the following results:

moo0

Now we can use this information to examine all the file system object permissions that were listed in the log we created. Granted this can be a tedious process, looking at each set of permissions one at a time. However if you’re patient this can lead to giving people access to the objects they need to run their applications without giving them rights to all the files on the file system (ie. Local administrator). There may be more steps you need to take, such as looking at the registry or user rights as well, but this is often a good place to start and often solves the problem for you.

Hopefully tools like this make it easier for you to give people only the rights they need to do their jobs. If you have other tools that you think will help, send us a note on Twitter at @isaudit. We’d love to hear what’s worked for you as well.

The Danger of Local Windows Administrator Rights

A couple weeks ago I wrote a blog post about limiting local Windows administrator rights – the importance of it and some of the things organizations can do to allow end users to work without having those rights (http://bit.ly/1hpyllB). One of the questions that has come up, and it always does, is the question – how bad is it if users have local administrator rights?

Obviously the easiest answer is BAD, REALLY BAD! It’s like you buy a house or a car and then decide that you don’t need locks on any of the doors. The reason we have file permissions, registry permissions, user right assignments, and the like in Windows is to limit ourselves to only having the rights we need on a system that are necessary in order for us to do our jobs. We shouldn’t have any more or any less rights than are necessary. But when we give our end users administrator rights, it is like we’ve just taken all the locks off the doors and given those users the ability to go into any room of the house without our permission.

Ok, so beyond the simple answer, what else could happen on a machine if we allow users to be local administrators of their machines? Here are just a few of the things that could happen:

  1. System files can be accessed or changed.
  2. Program files or program configurations could be modified.
  3. Software that is not approved could be installed, and won’t be maintained.
  4. Malicious code can be installed with unlimited rights.
  5. New, unapproved user accounts could be added to the system.
  6. Password policies could be subverted.
  7. Security controls such as anti-malware, firewalls, removable media controls, could be disabled.

And as you can imagine, the list goes on and on…

One other fun issue to consider is the issue of passwords. Many people have heard of the pass the hash attack where an attacker steals the local password hash from a machine and then replays it into the system’s memory whenever they want to authenticate as that user. This attack is certainly possible when users have local administrator rights. But wouldn’t it be easier if the user could just steal passwords out of memory in clear text instead? Well it turns out that’s possible too. Enter Mimikatz.

For a nice long, technical explanation of how Mimikatz works, there are plenty of nice tutorials (although to be fair many of them are in French). But here’s the bottom line, if your users are local administrators on their Windows machine, then they will by default have the user right assignment of “Debug Programs” (or they can assign themselves this right if it is taken away by a security policy). Once they have this right they have the ability to interact with sensitive portions of memory, such as those where authentication credentials are stored. With that information they are able to read authentication credentials out of memory as seen in the following screen capture:

mimikatz

Not only are we able to read the NTLM password hash out of memory – which could be taken offline and cracked or used in a pass the hash attach, but we are given the passwords for every logged in user in plain text. Even in the above example where the user is utilizing upper case, lower case, numbers, and special characters and a long password, there is no need for the time or computing resources to crack the password because it is there in clear text.

Many people might wonder at this point, is this only in older versions of Windows? Unfortunately the answer is no. Version 1.0 of Mimikatz works all the way through Windows 8 systems (although Windows 8.1 does appear to be safe). Version 2.0 of Mimikatz works even with Windows 8.1 systems to manipulate this type of information. And if you were wondering, yes, there is integration between Mimikatz and the Metasploit framework to make your penetration testing efforts easier. And, just because, there is also a plugin for Mimikatz for Volatility if you’d like to play with this tool with offline forensic memory dumps.

So once again, let’s restate the issue. How bad is it if end users have local administrator rights on their Windows machines? It’s BAD, REALLY BAD!! Both the Australians DSD in their Top 35 Mitigation Strategies document and the Council on CyberSecurity in their Critical Security Controls document list this issue as a serious concern. Hopefully we can all make sure to keep this issue in mind as we defend our systems.

Sensors for the Critical Security Controls

Most people in information security have heard of the Critical Security Controls these days. The idea of a community risk assessment project that helps all prioritize our information security efforts is appealing to most of us. The sticking question everyone always comes back to though is “how do I start implementing an information security plan using the controls?”

There are a few different approaches to this question. One of the most common is to simply start at the first priority (#1) and work your way through the list. It’s designed to be simple to use.

Ideally though we would have a translation between business requirements and what technical sensors security analysts need to deploy in order to achieve all the goals defined in the controls. So we took it upon ourselves to answer that exact question. If someone would take every sub control in the Critical Security Controls (version 4.1) and map a corresponding sensor to each of the controls, what controls would be left.

This is the list that we came up with (in priority order):

  1. Hardware Inventory System
  2. Asset Inventory System
  3. Active Device Discovery Tool
  4. Passive Device Discovery Tool
  5. System Imaging & Cataloging System
  6. Authentication System
  7. Public Key Infrastructure (PKI)
  8. 802.1x Authentication System (RADIUS / TACACS+ / etc)
  9. Network Access Control (NAC) System
  10. Software Inventory System
  11. Software Whitelisting System
  12. SCAP Compliant Vulnerability Management System
  13. SCAP Compliant Configuration Scanning System
  14. Configuration Policy Enforcement System
  15. Patch Management System
  16. Vulnerability Intelligence Service
  17. File Integrity Assessment System
  18. Anti-Malware / Endpoint Protection System
  19. Email Anti-Malware System
  20. SPF DNS Record
  21. Web Based Anti-Malware System
  22. Web Application Firewall (WAF)
  23. Application Code Review / Vulnerability Scanning System
  24. Database Vulnerability Scanning System
  25. Application Specific Firewalls
  26. Wireless Network Device Management System
  27. Wireless Intrusion Detection System (WIDS)
  28. Backup / Recovery System
  29. Data Encryption System
  30. DHCP Server Logs
  31. Domain Name System (DNS) Monitoring System
  32. Host Based Data Loss Prevention (DLP) System
  33. Host Based Access Control Lists
  34. Host Based Firewalls / Endpoint Protection System
  35. Intrusion / Malware Detection System
  36. Log Management System / SIEM
  37. Network Based Data Loss Prevention (DLP) System
  38. Network Devices that Support VLANs & ACLs
  39. Network Proxy / Firewall / Monitoring System
  40. Password Assessment System
  41. Removable Media Control / Endpoint Protection System
  42. User Account Discovery / Inventory System

It certainly seems like a long list, but I would bet most companies already have many of these controls in place.

It seems to us if an organization would work their way through this list as a part of a gap analysis and then review the controls, they would find that they hand implemented the majority of the sub controls in the list simply by implementing these sensors. Certainly an organization will need to operationalize the controls too. But at least this might help a few organizations to get started in their efforts.

Critical Security Controls Maturity Model

One of the projects that we have been thoroughly engaged on at AuditScripts.com has been to work with the Council on Cybersecurity on the Critical Security Controls project. If you haven’t had a chance to see the project, I would strongly recommend that you take a look. The full text can be most easily found at the SANS Institute at the following link:

http://www.sans.org/critical-security-controls/

One question I get asked a lot is regarding maturity models and the Critical Security Controls. Is there a maturity model that I can use to measure myself against to see how I compare to other organizations implementing the controls? At this point the official answer from the Council is “No, there is no official model.” However that being said, there’s also quite a bit of discussion around what might constitute a solid maturity model.

To answer this question I think the first thing we need to understand is that the controls are not just a list of good things to do. They also compose a mentality and philosophy for securing information systems. Therefore to understand a potential maturity model, we have to understand the guiding principles that the controls teach. The core philosophies of the controls are:

Offense informs defense: Use knowledge of actual attacks that have compromised systems to provide the foundation to build effective, practical defenses. Include only those controls that can be shown to stop known real-world attacks.

“Prioritization: Invest first in controls that will provide the greatest risk reduction and protection against the most dangerous threat actors, and that can be feasibly implemented in your computing environment.

“Metrics: Establish common metrics to provide a shared language for executives, IT specialists, auditors, and security officials to measure the effectiveness of security measures within an organization so that required adjustments can be identified and implemented quickly.

“Continuous monitoring: Carry out continuous monitoring to test and validate the effectiveness of current security measures.

“Automation: Automate defenses so that organizations can achieve reliable, scalable, and continuous measurements of their adherence to the controls and related metrics.”

That being said, it seems like a good maturity model would need to be composed of more than just “What percentage of the controls have you implemented.” So in anticipation of the various summits held on the controls this year in London and Washington, DC, we created the following maturity model for organizations looking to measure themselves:

Level #0:              Project Initiation

Level #1:              Some Controls Implemented & Audited

Level #2:              All Controls Implemented & Audited

Level #3:              All Controls Automated

Level #4:              All Controls Reporting to Management

Level #5:              Continuous Monitoring & Remediation

This is meant to be a high level statement, not a deep dive or project plan. But I think it could be the start of an interesting discussion. Companies need to do more than simply check boxes that they’ve implemented the right controls. Those controls need to be integrated into business processes, automated, and placed in the hands of knowledgeable business owners. Hopefully this model encourages us to start considering each of these aspects as we judge our maturity.

Critical Security Control Whitepapers

In some of our training we’ve mentioned to people that we’ve published a number a whitepapers on the Critical Security Controls in conjunction with the SANS Institute and various other vendors. Unfortunately we’ve also discovered that many of these whitepapers can be difficult to locate on the SANS Institute’s website. So we wanted to compile a list of some of the more relevant whitepapers that we think might help people in their efforts implementing the Critical Security Controls.

Here’s a list of some of those whitepapers with their links:

A Real-Time Approach to Continuous Monitoring (http://www.sans.org/reading-room/analysts-program/netwitness-splunk-monitoring)

Network Security: Theory Versus Practice (https://www.sans.org/reading-room/analysts-program/breaking-point-network-security)

Implementing the 20 Critical Controls with Security Information and Event Management (SIEM) Systems (http://www.sans.org/reading-room/analysts-program/siem-systems-arcsight)

Reducing Federal Systems Risk with the SANS 20 Critical Controls (https://www.sans.org/reading-room/analysts-program/20CriticalControls)

Streamline Risk Management by Automating the SANS 20 Critical Security Controls (http://www.sans.org/reading-room/analysts-program/streamline-risk)

Reducing Risk Through Prevention: Implementing Critical Security Controls 1-4 (http://www.sans.org/reading-room/analysts-program/tripwire-reducing-risk)

We hope you find these helpful as you consider utilizing the Critical Security Controls as a part of your information security architectures. If you ever have any questions on the subject, please don’t hesitate to reach out to us at [email protected].