The days of perimeter defense-based security are now behind us. And they have been for awhile. With the ubiquitous proliferation of smartphones, laptops, and employees working from the road, the traditional concept of a “network border” has evaporated. Yet, even before this started to take place, the black-hats-turned-white-hats and other front-line operators would scream for defense-in-depth.
Anyone who’s ever done a thorough investigation of a widespread network intrusion, generally discovered these three facts:
1) The bad guy got in and moved around a lot inside
2) The bad guy has been inside for a while, on average 99 days*
3) There was no way to have pro-actively closed all holes
This concludes that a network with a solidly defined border cannot abide by border defenses alone. Eventually, someone gets in. And it is the moving around on the inside where the bad guys spend most of their time.
As a system is compromised it becomes a stepping stone.
Intel gathered on the system allows the intruder to move laterally in the network. This intel could be a network layout, common applications, services that the organization uses, or even credentials for other accounts and resources in the organization that allows the attacker to penetrate further.
With each step, more of the network is mapped out and more data is discovered. By understanding what applications are commonly used, the attacker might perform limited scans of the resources, and attempt exploits in a targeted fashion. The days of widespread network scanning are over, as such behavior is way too loud and easily picked up by sensors.
As some attackers become more stealthy and methodical, it has become much harder to successfully and quickly detect them. That is likely the leading reason that time-to-detection has not gone down, despite an explosive growth in the security technology industry. Because of this, the security operator has been forced to adopt a more active role, instead of detect-only.
Good cyber hunters search for patterns of connections, patterns in logs, or connection behaviors that are not expected in the normal course of business. And instead of acting on alerts (which are “positive indicators of compromise”) they take time to map out the extent of the treat in their network. This is borne from the realization that an intruder may have penetrated the network much deeper than the current evidence may support. In other words: if the bad guy is deep inside your network and has their hands into many resources, shutting the attacker down in only one of them, tips your hat. The attacker now knows they are being watched and will change tactics.
Cyber hunting is all about understanding the full extent of the compromise before any action is taken. And this is hard. Because there are many ways in which someone may move laterally through the network. For this, widespread visibility is the key. To stack the deck in the favor of the hunter, we turn to a technique that has been around for decades: decoys.
A decoy can be as simple as an email account without a real user, and as complicated as a server full of resources that are out there “to be discovered”. The latter is also called a “honeypot”.
By leading the attacker astray, you accomplish two important goals:
1) The mere act of an attacker touching these decoys is a red flag
2) The attacker now is chasing fake leads on your network, which takes time, and makes more noise that can be observed
The downside of decoys are myriad, and a commitment must be made to watch them carefully. They are hard to put together realistically, taking significant operator time. And they must be monitored carefully, as they can in themselves become stepping stones or platforms for launching attacks into the world. When placing decoys, it is also very important to ensure your visibility is “out-of-band”. It should not be trivial for the attacker to understand you are closely watching the decoy, or even disable your visibility. In general, it must be hard for an attacker to understand they have hit upon a decoy.
Security remains a cat & mouse game, and it goes without saying that a perfectly secure network does not exist. Using decoys as a trap for the advanced intruder can pay off in spades, but the investment must be carefully and deliberately made. More important still, a comprehensive network of visibility and data gathering must be in place before even attempting the deployment of traps in your network. After all: what good is a tripwire, if you aren’t listening!
Look for next week’s blog on tips on how to successfully build and watch a decoy.
*Source: Gartner, June 2017
We recently examined achieving PCI compliance in a public cloud environment. In that article, I gave a high-level overview of the steps you need to perform. In this article, I would like to dive a bit deeper and discuss some of the unique challenges you can run into, and your options for resolving them. As I hinted in the last article, the biggest challenges can revolve around meeting the network specific controls within the PCI DSS framework.
Cloud providers can receive a PCI DSS attestation as a Service Provider. This permits them to offer services to customers that need to process credit cards as part of their business model. It also permits them to offer services to other cloud providers that expect to have an impact on credit card transactions. For example, Amazon maintains an attestation as a PCI DSS Level 1 Service Provider. This means any third party company could build a Software as a Service (SaaS) offering capable of achieving PCI DSS compliance on top of that infrastructure. This is sometimes referred to as “nested vendors.”
One of the required documents a cloud provider must maintain is a Report on Compliance (ROC). This defines the level of responsibility assumed by both the cloud provider and their customers for each PCI DSS control. In some cases, the provider may assume full responsibility (example: data center physical security). In some cases, the vendor may assume no responsibility (example: checking customer code for security vulnerabilities). In others, implementation of the control is considered a shared responsibility (example: vendor supplies a firewall but customer must properly configure it). You need to review the ROC and provide coverage for all controls to which the provider does not accept full responsibility.
Let’s look at an example of a PCI DSS control that can be extremely challenging to put in place if your provider does not accept full responsibility. Figure 1 shows the control requirements included in control 11.4:
The control requires that a Network based Intrusion Detection or Prevention System (NIDS or NIPS) be installed and maintained. While the description does not specify a network or host based system, the bullet items specify that it be installed at the “perimeter” and “at critical points,” which implies a network deployment rather than host based. In a cloud environment, the provider includes networking services. However, they typically do not accept responsibility for this control. This leaves you in a position of having to implement a control within an infrastructure that you do not administer.
One possibility is to attempt to implement a compensating control. This is permitted when there is a legitimate hindrance to implementing the control exactly as described. Since you don’t control the network layer, you could argue that you are technically unable to implement the control as it is described. You could further argue that a compensating control would be to run Snort, or similar NIDS software, on either every host within the provider’s environment or on a dual-homed server acting as a gateway in front of all other servers (assuming the provider supports this type of connectivity). You could then argue that this creates a similar level of security to that which is described by the PCI DSS control.
However, pursuing this path brings its own set of challenges. You are deviating from the control as it is described. Your Qualified Security Assessor (QSA) may or may not agree with your assessment, and thus may or may not consider this control to be in place. You may put a lot of work into implementing a compensating control, only to find out that you need to identify another solution. Further, just because a QSA accepts a compensating control once, does not guarantee they will do so in future assessments. It is entirely possible that a compensating control can get accepted one year but rejected the next. Since the acceptance of a compensating control is a subjective evaluation, final judgment can vary between assessments.
Finally, both of the described possibilities create additional administration challenges. In the case of running Snort on every box, you have to administer the overhead of having Snort running on every system. A centralized infrastructure must be created, and Snort will take processor and disk read/write time from whatever production processes are also running on each system. While running a gateway setup solves many of these challenges, the configuration is not supported by all cloud vendors and even if it is, you can end up with a single point of network failure. So while compensating controls are possible, they should be considered an option of last resort.
A common mistake I hear is that Netflow or IPFIX data cannot be used to meet PCI DSS control 11.4. The assumption is that since this data does not include payload information, it does not qualify. Let’s carefully reread control 11.4 and extract out all listed requirements:
Note that the defined purpose is to alert personnel when a system acts suspiciously and is potentially compromised. A NIDS that analyzes payloads is not going to give you this information. For example let’s assume an attacker launches an inbound injection attack, which is the top listed OWASP vulnerability. Most likely the attack will take place over HTTPS. HTTPS provides data privacy, which will prevent the NIDS from being able to eavesdrop on the session. Thus the attack will go undetected. Further, even if HTTPS is not used and the attack is detected, this does not guarantee that the target system is actually vulnerable. All we know for sure is that someone attempted the attack. Triggering a response when the success of the attack is not confirmed is going to generate a large number of false positive alerts.
So how do we detect suspect compromises? By identifying when the system acts suspiciously. For example, assume we have a publicly accessible Web server. What type of outbound session establishment is required by this system? Here is a common list:
This is a pretty short list. We could easily define a set of rules that ignores all traffic that meets the above-defined criteria. We then trigger an alert whenever an unexpected traffic pattern is detected leaving the system. We could do this with a classic signature based NIDS, or we could do this with IPFIX flow data. We do not need to analyze payloads to detect this type of suspect activity. The benefit of using flow data is that we do not need to deploy an entirely new security system.
We have established that NetFlow or IPFIX data can be used to meet PCI DSS control 11.4. This leads us to our next challenge, which is that as of the time of this writing, no public cloud vendor supports IPFIX. However all is not lost, if you have instances running in Amazon, you can convert their VPC flow logs to IPFIX format.
I’ve written an article called Working With VPC Flow Logs. If you are new to Amazon flow logs, this may be a good place to start. Once you’ve read that, you can move on to Alex Barsamian’s great article on the configuration as well as importing flow logs into Flowtraq. This can help you get up to speed quickly in meeting this control.
Leveraging public clouds that are PCI DSS compliant is a great way to reduce the number of control to which you are responsible. This can create new challenges, as you need to satisfy controls within an infrastructure you do not administer. Combining tools such as Amazon’s flow logs with FlowTraq can help you meet this control quickly and effectively.
On May 12th, 2017, a widespread global ransomware attack began traveling through vulnerabilities in the Windows operating system. It has struck over 150 countries and a broad range of industries. More than 45,000 attacks have been recorded so far, ranging from UK National Health Service to FedEx.
It has yet to be discovered who is behind the attack. However, a twenty-two-year-old cyber security researcher registered a domain name hidden in the malware which has currently stopped the spread of the attack. This has given organizations in the US more time to develop immunity to the attack. The attack is likely not over. Cyber criminals often change the code and start again. Microsoft released a patch (a software update that fixes the problem) for this window operating flaw in March 2017, but pirated programs and computers that have not installed the security update continue to remain vulnerable.
Since, it’s random, scattered and broad it’s hard to know where it may hit next. It’s important that all organizations are patching their Microsoft operating systems before they are infected.
After a security weakness, or a malicious link clicked from your email, the ransomware installs itself, and encrypts some or all of the files on your computer with a secret key, so you can no longer open them.
In order for you to un-encrypt your files so you can use them again, you must pay an amount of money to the attacker. This is usually paid in bitcoin. Once you have paid, the attacker gives you a key with which to unencrypt your files. Keys are typically specific to your computer, so a different key must be used on each system that has been infected with ransomware.
If you’ve been hit by WannaCry Ransomware, you’ll see the following on your screen: “Oops, your files have been encrypted!”
1.) Ransomware is a real threat, much like credit card theft, electronic banking hacks, and electronic espionage.
2.) If you haven’t already, patch or disable Microsoft immediately. More information can be found here.
Your organization can protect itself by following the golden mantra of update, educate, and separate:
You may not always care about minor bug fixes or features but you should always keep major apps, programs and operating systems like Windows, browsers and PDF readers up to date. Setup automatic updates and/or calendar reminders.
49% of data breaches are caused by malicious or criminal attacks, and 19% are related to employee negligence (Source: Cost of Data Breach Study by the Ponemon Institute.)
A lot of ransomware is simply emailed to people, and requires them to click on a link in order for the computer to be infected. This is commonly called “phishing”. Once the user knows how to recognize links and attachments, and be distrustful of them, the changes of ransomware taking hold of your environment quickly diminishes.
Gain support from your senior leadership by knowing the business risks and consequences to the company in regards to data breach. Ensure your employees are not using pirated software and that all software is up to date. Educate and train your employees on how to handle confidential information and email safely. Commit to security best practices as an organization.
A strong firewall on the perimeter is worthless once the attacker and his/her ransomware are in the door, and has free reign inside. So build a network of levies, so security breaches don’t spill over from one segment to the next.
When your daily defenses are in decent shape, hunt for compromises daily. It is important to realize you are fighting a human attacker, who is smart about the defenses that you could have in place.
Collect flow data from all routers and switches in your network, and let a behavior anomaly detector do its work. Collect logs from all servers, access points, and workstations. Hunt for obvious malicious activity, investigate each anomaly, and watch for movement of large amounts of data on your network.
There is no such thing as a 100% secure network, but by just doing the legwork you are a long way on your way to keeping ransomware off your network.
Gain visibility on your network around the clock and set up alerts. Learn more about FlowTraq Cyber Threat Hunting.