How to Prevent/Detect Security Breaches with the Help of Regulators

As security professionals we struggle with several challenges. Defining standards or meeting regulatory compliance can be one; and preventing security breaches can be another. One should help with the other, but sometimes good enough just isn t. Sometimes we miss a solution by spending too much time thinking about the problem. The most fundamental security problem to control is user access.

I attended a conference yesterday in which my friend and colleague Stuart McClure was a panel participant along with law enforcement, regulatory agencies, and a Chief Privacy Officer from a large software company. During the Q&A series there was a lively debate between the regulators who write the audit and governance reporting rules, the Chief Privacy Officer and the other participants who deal with incident response including Stuart and two Assistant US Attorneys. The point was made that regulators need to write rules that are general enough to be applied by everyone, without the specificity that might cause companies to rise only to the level of compliance. The counter-point was made that companies already do that (only commit to compliance), and accordingly that the rules should be more specific and focused on the basic security problems that actually underlie all breach events. Between the two arguments though there was agreement on one truism: prevention is the key to security.

While we listened to the panel discussion I realized that there seemed to be a gap in understanding by the participants for what each other were saying. On the one hand the regulators expressed frustration that they wouldn t be able to deliver a standard for auditing security controls that would be acceptable and still useful; on the other hand the responders expressed frustration that simple but specific guidance could not be provided for compliance auditing and reporting that would help to prevent security breaches - not to mention the fact that the industry and regulators have been providing high level guidance for operators for the better part of 20 years (such as FERC/NERC CS, FISMA, GLBA, HIPP, NIST, ISO, and etc.) with the result that auditors review company controls to meet compliance standards, but threats have continued to evolve without related evolution of the standards. It is impossible to prevent something that you are not even watching out for.

It also occurred to me that maybe people do not realize how simple security breaches are to carry out and how simple it can be to prevent them. In fact there has always been and audit criteria for information governance related to security controls that could help immensely if applied from a different perspective.

I m talking about user profile monitoring. Ask yourself, How many computers in my organization have how many different user profiles on them, and when were they created or subsequently used and how? Answering these questions will focus your security breach investigations tremendously and help to dramatically identify lateral movement by unauthorized (or otherwise anomalous) users in a corporate network. Investigating the user history reveals accesses to information sources and subsequent actions by the users that may include further compromise, reconnaissance, targeting, sabotage, or exfiltration of data.

There has long been a standard for auditing "RBAC" (Rules or Roles-Based Access Controls) in databases related to material information in companies such as ERP or CRM systems; however there is no such standard requirement for auditing "User Profile Propagation and Use".

It sounds like quite a complex challenge, and very technical or intrusive but in fact it need not be. A survey of the computers in the company network for the date of creation of user profiles on systems, or their use according to Security event (or access) logs, is simple if you have a basic understanding of the file systems that support the Windows, Mac, and Linux Operating Systems (O/S).

Warning! Technical stuff follows!

In Microsoft Windows, the user history is maintained in a profile folder named for the user account that is accessing the computer. The user history file is called "NTUSER.DAT" and contains a registry of user settings such as accessibility to other computers, applications, and information stores. The naming convention is <drive letter>:\Documents and Settings\<user profile> or <drive letter>:\Users\<user profile. In Linux a similar convention is used but the path is /home/<user profile>, in Mac the path is /Users/<user profile> - and settings and commands history for both O/S types are contained in files within the profile folder (.bash_profile, or .profile, and .bash_history ~ or the equivalent if KSH etc. are used), or /Library/Preferences/*plist files in Mac for related application settings.

Figure 1 WinXP User Profile

Figure 2 Win7 User Profile

Figure 3 Linux User Profiles

Figure 4 MAC OSX User Profiles

Secure authentication to log on to a Windows workstation is recorded (when actually logged by a company ) in the Windows Event logs (see Figure 6). In Linux and Mac it is recorded in/var/log/auth_log  see Figure 5 and 7. Network logs may also be available from Domain Controllers for Active Directory, LDAP, TACACS/TACACS+ or other authentication mechanisms such as VPN logs as well; though in my experience many companies do not maintain those logs as they can become very large very quickly. Our colleague Gary Golomb did an excellent review of Windows Event logs recently so I won t repeat the details here, but suffice it to say that Event logs (whether Windows, Linux or Mac) can contain a great deal of useful information for understanding who did what, when, and how.

Figure 5 Linux Authentication Logging

Figure 6 Windows Authentication Logging

Figure 7 MAC OSX Authentication Logging

London Calling

I was asked to participate in a security summit for a large US bank a few months ago. During one of the sessions someone asked How can we change our security awareness posture? I brought up the issue of user profile monitoring and their response was - that it is impossible to do. That is a response that we hear from nearly every company that we work with, large or small. The point is always made that there are no tools for efficient monitoring of user profiles in order to identify anomalous use.

As the venue was a bank I thought this was ironic. I related to the bank IT staff and other attendees that whenever I travel internationally I have to ensure that my bank(s) know that I am traveling. However no matter whether I notify them or not, for some reason whenever I travel to London and attempt to make a purchase with my credit card, it is declined and I am required to call the bank to verify that it is indeed me, and they validate my identity through my responses to my personal security questions.

Even when it is a nuisance it is still comforting to me as a security professional to know that someone at the bank is monitoring my user activity profile to identify anomalous use and take simple actions to notify me and validate my identity. I asked the bank IT staff why they provide this capability for customers, but not for IT users?

How to fix the problem in three easy steps

Step 1 Monitor

We have had the discussion with many customers about monitoring user profiles not for what they are doing as much as where and how. A common theme in responses is that it is difficult to identify anomalous activity by users who travel frequently, or work from home, or work on the weekends in other words the profile of today s American worker!

At one client s site we noticed that HR policy required all personnel to maintain their electronic calendars (in their email client) so that where they would be was included whether out of the office for a meeting, lunch, or vacation. We suggested that a simple LDAP connector between their Active Directory authentication and their email calendar could monitor and alert when their user profile was being used, and on which systems. Then at least it would be logged for review if needed, or could be alerted to help desk personnel who work 24/7 globally to call the user, or require the user to call a service number to authenticate as happens with my bank me when I try to use my credit card in London.

Again, the problem sounds more complex than a simple solution that can actually help.

Step 2 Alert

Another client uses McAfee EPO as their primary Management Console. We recommended that they create a rule so that whenever a new user profile is created on a computer anywhere in their enterprise network, that EPO logs the activity. This monitoring rule simply involved defining an EPO Client rule for the detection of a new NTUSER.DAT file in the %USER% path of the client workstation. On the EPO Management Console any new profiles that are created will be automatically logged and can be filtered for review or alerted to help desk or incident responders accordingly.

We also recommended that they alert the use of desktop default Administrator (or Admin) accounts, and the use of other domain administrator accounts. Even though there are many help desk or other administrative accesses made to computers in the course of normal business most companies have ticketing systems that can relate to legitimate use of those credentials; and if they don t have a ticketing system this can be a poor man s version of one for monitoring purposes that coincidentally helps to discover anomalous use of such credentials.

Additionally, when compromised user credentials are discovered, or when employees/contractors have left company employment we always recommend the accounts be deleted or at least retired . Then we recommend that alerting rules be placed through GPO or Active Directory for attempted uses of those user profiles. We have found this to be a very simple but very lucrative source of information in APT investigations to identify hosts that we were unaware had been accessed, or subsequent credential uses (or other tools and access points or methods by attackers into the network).

A little goes a long way.

Step 3 Audit

Most companies use some form of change control or change management software, such as Altiris or Microsoft s SCCM. A periodic audit of the directories where user profile histories are created can provide very useful information for determining anomalous or potentially unauthorized logons to computers. Further, auditing for certain other artifacts of information related to the use of common remote administrative tools such as Microsoft Terminal Services (MSTSC) like .rdp or .bmc files in user profile subordinate directories, VNC, command shell NET USE, or similar can be done simply as well.

Even if a company doesn t use change management software, the audit can be as simple as this command:

 dir /a /s /od /tc c:\ntuser.dat *.rdp *.bmc 

this command can be used in a batch script and the results written to a share location for auditing of the enterprise computers as well.

 @REM Collect User Profile History Dir /a /s /od /tc c:\ntuser.dat *.rdp  *.bmc >> \\<sharename>\%computername%.txt  

Or audit the event logs

 @REM Collect Logon Events @REM WinXP cscript %SYSTEMROOT%\system32\eventquery.vbs /v /l security /fo csv /fi "ID eq 528 or ID eq 540 or ID eq 533 or ID eq 534" > \\<sharename>\%computername%_logons.txt @REM Win7 wevtutil qe Security /f:xml /rd:true /q:"*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and Task=12544 and (EventID=4624 or EventID=4625)]]" > \\<sharename>\%computername%_logons.txt 

http://technet.microsoft.com/en-us/library/cc787567(v=ws.10).aspx
http://technet.microsoft.com/en-us/library/dd941635(v=ws.10).aspx
http://msdn.microsoft.com/en-us/library/aa394189.aspx

and GREP similar information (logons by UID or connections by IP etc.) for Linux / Mac.

Then compile the events into a database and use correlation analysis by date/time, user profile name, event type, Source Address, or etc. to understand the "lateral movement" between systems that may indicate the malicious use of user profiles in the enterprise.

KISS Principle

Whether approaching an incident response or a security audit we always start with the most important information first from available evidence:

1. Was data stolen or sabotage conducted?
2. What user profiles were used on which systems and when?
3. How did users access other computers laterally in the network?
4. What malware or other IOC's are helpful to understand the history of activity?
5. What build discrepancies may identify vulnerable applications or systems?

Of these (prioritized) questions, perhaps the most important and illustrative artifact of malicious or at least anomalous activity in the security events is the user profile, its propagation, history, and very existence on disparate computers in the enterprise. This one element of information in the incident puzzle can help to unravel what happened, when, where and how.

We don't have to recreate the wheel, we just have to use it more effectively.