Sunday, March 30, 2014

A kill chain analysis of the Target breach

Here's a link to download a PDF sent to the senate regarding an analysis of the Target data breach. Nothing all that new, but a good read nonetheless.

It seems that Target had ample opportunity to deter the attackers, but never did. Target's a wake up call for all operations and monitoring teams. 

Friday, March 28, 2014

Ensuring Network Security When Working with Third Party Vendors: Part 1 of 2

When it comes to network security and attempting to protect the digital assets of your organization, you’re only as secure as your weakest link. I can’t help but think of Anne Robinson from the corny BBC game show “The Weakest Link” each time I hear this phrase now, but it’s true.
The soft underbelly for many organizations is not their network per se, but the networks of those they’re doing business with. These third party vendors might not be as security conscience as you are, but in the long run, it’s still your network and your (and your customers’) information. The headlines will focus on the data breach and ultimately it’s your fault. In this two-part blog series, we'll examine some important steps to take for limiting the damage caused by insecure third party vendors (which by the way is an important aspect of PCI-DSS compliance):
  • On-boarding New VendorsTo start off there needs to be a process of vetting potential vendors. Not every vendor is going to be given the green light to perform business with a company. There needs to be a process of on-boarding new vendors so that your data isn’t being strewn to just any company. The process needs to include your risk management or information security team from the beginning, before the PoC or data sharing, so that they have the appropriate amount of time to research the vendor, contracts, data sharing, etc. If this is done after contracts are signed, you’re playing catch up and it’s difficult to have something removed once it’s put in place.  Having a team responsible for determining the risk of vendors early on in the process is a huge win. This can be added to the legal request or whatever other method that’s used to establish a relationship with new vendors. Once this is established there also needs to be education within all the other departments to understand the new process. It’s not going to work overnight and everyone needs to be on the same page for this to work properly.
  • Checklist and ContractsOnce a third party vendor has been reviewed and you have an understanding of what they do and why they’re needed, you can start with the checklist and contract phase. In order to truly vet a vendor you need to understand what they will be doing with your data. Creating a checklist of questions for the vendor to answer is highly recommended so that you can have a physical copy of what they say they do and how they do it. This checklist should also be signed by both parties involved and saved with the other documentation that’s needed to setup a vendor relationship. A checkout process should be included to keep the most up-to-date copy of this checklist available for review. I’ve seen these checklists be as little as four pages and as long as 30 pages and they provide you with a good understanding of how the third party does things before blindly handing over your data to them. Here are a few questions that I’ve seen in these checklists:
  • Will the [ENTER COMPANY NAME HERE] data be stored outside the United States of America?
  • Does [THIRD PARTY VENDOR] have an incident response program?
  • Who has access to [ENTER COMPANY NAME HERE] data? Is it role based and audited?
  • Are firewalls, IPS and log management used?
  • Etc.
Normally, I’ve seen these checklists broken down by topic with multiple questions entered under each topic. A few of these topics are infrastructure, data governance, system configuration, privacy, compliance, and more. Based off these topics and the questions that you submit under them, you should be able to get a fair understanding of how the potential vendor will treat your data.
Now I know what you’re going to say… what if they just lie and put what you want to see down as an answer to a question? Yes, that’s a concern… and a big one. We initially give vendors this list to see what their posture is, but if they’re lying to us we’ll have no idea. In order to give them a little more skin in the game you can add the checklist to the contract being signed with legal and put in a clause about giving you the right to audit them if you deem it appropriate. I guarantee you that the vendors are going to push back on this request, but if they want to do business with you, it’s a price they’ll have to pay. Plus, by having this added to the contract you can have them responsible if data was lost on their end and they were lying about what they were doing in the checklist. It helps keep people, um, honest.
In my next post, we'll continue to look at ways to shore up your weakest security links when it comes to third party vendors – from data access to incident response and cybersecurity insurance.

Security Breach Analysis: Are You the Next Target?

The Target security breach is another eye-opening example that these compromises don’t just happen in the movies. This is going on everywhere and we need to protect ourselves from being the next Target (pun intended). With the limited information we know about the Target breach, there’s still quite a few lessons learned. First of all, let’s discuss a few things that Target has done well.
  • I think Target has taken responsibility about what occurred  and they haven’t been “hiding too much”. Some have said that Target knew about the breach for a few days before alerting the public, but so what!! The company was dealing with a criminal investigation and if it wasn't confident that the bleeding was stopped the company shouldn’t alert the world that there is a problem – it could cause the investigation to change and tip off the attackers. I personally think what they did was more than appropriate.
  • With all the phishing and misinformation going around due to the breach, Target’s set up a page on their site to be the authoritative place for details on the breach. This includes e-mails they’ve sent out, videos form the CEO, etc. You can visit that page here:
  • They brought in third parties right away to deal with the breach. For an issue this big, with a company as large as Target, third parties are needed to assist in the investigation. Law enforcement was brought in right away, as well as Mandiant (cyber investigators) to work the incident.
Now a few lessons learned. This isn’t meant to point fingers, but to learn from breaches in the past and do our best to ensure that history doesn’t repeat itself. There is no perfectly secure network and we shouldn’t be on our high horses when speaking about other breaches.
  • It seems right now that the POS breach was first started by a vulnerability in a Target website, with the attackers than going deeper into the network to attack the POS systems. Take note – your website will almost always be the most vulnerable part of your organization. It’s public and could potentially leave you open to large breaches due to its configuration. Keeping your public facing applications secured with proper vulnerability scanning, segmentation and monitoring is a must (read my blog series on network security design for more on this: Part 1Part 2Part 3 and Part 4).
  • Multiple articles reference that the Target breach had the data manually siphoned to an offsite server where the attackers collected almost 11GB of stolen information. This leads me to a few observations:
    • It doesn’t sound like proper egress filtering was occurring on the network if they were able to siphon data out of the network directly. If there was proper egress filtering occurring, FTP wouldn’t have been able to work on all servers.
    • The best case scenario is that they do have proper egress filtering, but that the attackers were able to determine which systems could exit via FTP. If this is the case they had complete access to the network to try and egress with FTP, which is more of an issue, because they had full reign and weren’t noticed.
    • Why was FTP allowed to go outbound to begin with? This is an insecure protocol and should be removed from your network if possible (watch this video to learn common firewall misconfigurations).
  • Monitoring and thresholds weren’t configured to alert the Target Infosec team that there was unusual activity occurring in the network.
    • Why was a user account created with admin rights without anyone noticing? Was this part of domain admins? Proper logging needs to be applied towards all systems with SIEM and correlation against suspicious traffic.
    • Netflow data should be pulled from the firewalls and routers to determine when something in the traffic patterns isn’t kosher.  Creating thresholds for “normal” traffic will assist when someone is dumping something out of your network, like 11GB of data via FTP.
  • How was the network segmented? I’m sure there was some type of network segmentation, since Target must comply with PCI-DSS, but there were obviously holes in it somewhere.
    • The attack seems to have started from the web, moved into the network and found the POS systems. They were pivoting across multiple segments of the network which is very interesting (attackers were able to get mailing addresses, e-mail addresses, etc. which means they were able to move outside of these systems and deeper into their network). We need to determine how to lock down these segments to only allow needed traffic into the appropriate networks.
    • Oh, and just because Target was PCI-DSS compliant, that didn’t make the company “Hacker proof”.
  • If you’re running a POS system in your network make sure it’s locked down.
    • The malware that was found was pretty nasty, but as the information comes out more about this breach we need to determine just how the attackers pushed it to so many terminals.
    • Did they compromise an account that had admin rights to send or install this malware across the network? Did the registers have local admin? Were these ever audited and secured? These are things we need to ask ourselves about our own POS systems.
As the story continues to unfold we’ll continue to get more details about the Target compromise, but for now we need to take away these lessons learned and either apply them to our network, or audit the existing configurations. We never want to see a breach happen, especially one that affects so many people, but if we don’t learn and change from it we’re doomed to be the next Target.

Tips to Secure the LAN: A Look at the Human Layer

Besides all the technology we talked about in the last two blogs that examined the network and application layers of the LAN, this next section is arguably the most important. Giving your users a proper security education can limit any of these technologies having to be used in the first place. If they’re not going to bring in the threats and are equipped with the knowledge to protect themselves, it’s a big win for everyone.
  • Empower your users with security training – Make sure your users are up on the latest trends and threats on the Internet. Giving them the power and education will save you hours of frustration later on. The key is making sure they know you’re there and that you’re on their side. They need to understand your goal is NOT to be big brother watching everything they’re doing – it's important for them to understand that you’re there to help secure the company and keep them safe. Create a relationship with them and run contests regarding information security, send out questionnaires or even surveys as to what they’d like to see in your training. Make them more involved with the program too.
  • Train them often early and often – Offer training in multiple formats because everyone learns differently - face-to-face, webinars, written material, etc.  Send out mandatory training that the users will have to take before coming into the company and every year annually. (Not all training should be enforced as you want users to WANT to get trained, but you have to enforce some of it to catch those users that aren't interested. Who knows… they might actually learn something.)
  • Communicate – Hang up posters around the office with security phrases. Make sure this is part of their corporate culture and maybe they’ll think twice before doing something potentially dangerous on the internet and to your company.
  • Make it fun – Put the training to the test, this is the fun part. Send out fake phishing emails, leave USB or badges around the office, call into user desk phones and try to get information out of them. This is the barometer to determine if they were listening. Also, don’t beat anyone up if they fail, this is a company wide effort. If one group doesn’t do well, they might all need additional training. This doesn’t mean we single people out, but if a few people in the group had issues, you can be sure that there are others who need training.
These three sections are just the tip of the iceberg when it comes to securing your LAN, but it’s a start. By applying a few of these areas into your network will assist with a strong security posture which you can continually add upon. The key is to add all three areas to create a layered approach. If you only install one area of these suggestions you’ll leave yourself open to attacks from a different angle. Try to enforce each area so that you have a well-rounded security posture around your LAN.

Tips to Secure the LAN: A Look at the Application Layer

Now that we have the LAN locked down at the network layer, let’s try and get the application layer tied up a little bit. This is going to include apps that allow for tighter control over the workstations within our LAN. These apps can be both software installed on the users workstation or applications that are in use between the workstations and the internet that allow for additional protection.
  • One thing that users hate in an organization is proxy/web filtering services. These are the systems that attempt to block all the “Cat Videos” that users are trying to click on repeatedly. This layer needs to be there to give the Internet access some type of “cleansing” before the users attempt to access the outside world. Once again, this isn’t bulletproof, but if it stops one incident from occurring it’s paid for itself.
  • Patch, patch, patch, patch. I was going to leave it there, but maybe I need some more explaining. You need to patch everything and you need to do it regularly on a repeatable basis.  To be clear, I’m not talking about having all your workstations set for “Automatic Updates” either. However if you’re patching your user workstations you need to have a process to deploy patches from a centralized console and allow for scheduled and out-of-band patches. These aren’t just from the operating system either, this is for all software. The biggest risk to your enterprise right now from a user’s perspective is third party apps. You can have all the fancy firewalls in place, but if you have an old version of Java installed with a weaponized “Cat Video” link that’s going to execute a payload through a Java vulnerability, you’re dead.  Patch all workstations, patch all software on them and patch often.
  • I’m going to make an assumption here and assume that you’re using a Windows based system in a corporate network. I’m sure they’ll be many people upset that I didn’t bring in Linux or Apple (be quiet fanboys), but I wanted to go with the most prevalent user workstation out there, Windows.  If you’re running a Windows domain within your infrastructure you should be relying heavily on Group Policies (GPO) to harden the workstations that report it. It’s here that you need to create policy on each system reporting to it like a password policy, enabling host firewalls, limiting administrator access, limiting the capability to insert USB drives, enabling UAC, etc. This is where the war is going to take place, so lock down those systems as best you can. Now, if you have Macs or Linux boxes on a windows domain you can still push policy to them with third party software. Something to take a look at.
  • Centrally pushing our anti-malware agents to each workstation is something that’s becoming less effective against persistent attackers, but it’s still a layer (see the pattern here)!! The key is to find an anti-malware vendor that has a decent rating (so few do these days) and make sure you have it installed on all systems. This can include a NAC, HIPS, AV, etc. client installed on the user workstation.

Tips to Secure the LAN: A Look at the Network Layer

In my last blog series we reviewed ways to protect the perimeter of your network and then we took it one layer deeper and discussed securing the DMZ. Now I’d like to examine the ways you can secure the Local Area Network, aka LAN, also known as the soft underbelly of the beast. Okay, I made that last part up, but that’s what it should be called. The LAN has become the focus of attack over the past couple years, due to companies tightening up their perimeter and DMZ. It’s very rare you’ll you see an attacker come right at you these days, when they can trick an unwitting user into clicking a weaponized link about “Cat Videos” (Seriously, who doesn’t like cat videos?!). With this being said, let’s talk about a few ways we can protect our soft underbelly and secure our network.
For the first part of this blog series, let’s examine how to secure the LAN at the network layer.
From the network layer there are constant things that can be adjusted and used to tighten the posture of your LAN. The network is the highway where the data traverses. We need protection on the interstate just as we need protection on our network. Protecting how users are connecting to the Internet and other systems is an important topic. We could create an entire series of blogs on just this topic, but let’s try to condense it a little here.
  • Verify that you’re network is segmented – it better be if you read my last article on the DMZ – but we need to make sure nothing from the DMZ is relying on internal services. This is a rule. Take them out now and thank us later. If this is happening, you are just asking for some major compliance and security issues to crop up.
  • Continuing with segmentation, make sure there’s a guest network that vendors can attach to if needed. I hate when I go to a client/vendor’s site and they ask me to plug into their network.  What if I was evil? What if I had malware on my laptop that’s now ripping throughout your network because I was dumb enough to click a link to a “Cat Video”? If people aren’t part of your company, they shouldn’t be connecting to your internal LAN plain and simple.
  • Make sure you have egress filtering on your firewall so you aren’t giving complete access for users to pillage the Internet from your corporate workstation. By default users should only have access to port 80/443, anything else should be an edge case (in most environments). If users need FTP access there should be a rule and you’ll have to allow them outbound after authorization, but they shouldn’t be allowed to rush the Internet on every port. This stops malware, botnets, etc. that are communicating on random ports. It doesn’t protect everything, since you can tunnel anything out of these ports, but it’s a layer!
  • Set up some type of switch security that’s going to disable a port if there are different or multiple MAC addresses coming from a single port. This stops hubs from being installed in your network and people using multiple workstations. Also, attempt to setup NAC to get a much better understating of what’s connecting to your network while giving you complete control of those ports and access to resources from the LAN.

The Ideal Network Security Perimeter Design: Part 3 of 3 - Examining the DMZ

Following our last blog on creating and securing the DMZ, we will take a look at how to safeguard the DMZ from within. But first, let's quickly recap our journey throughout this "Ideal Network Security Perimeter Design" series…
Ok, now let's dig into how to layer security within the DMZ. Sometimes people are sure to lock down the DMZ from an external perspective, but forget to put that level of security on access to the DMZ from an internal perspective. Of course you’ll have to access, manage and monitor these systems too, but you’ll do so in a slightly different manner than you would with systems living on your internal LAN. Access to the DMZ from an internal perspective should be locked down as tightly as possible. These are systems that can potentially be holding sensitive data or have access to other systems that have sensitive data. If a DMZ server is compromised and the internal LAN is wide open, attackers suddenly have a way into your network.
Limiting Access to Systems within the DMZ
From an internal perspective we should limit who can access systems within the DMZ. Creating firewall rules to only allow the source IP addresses and port to the specific server is a start to security, but we should really go further than that with other filters. Creating proxies or jump points in the network from which administrators are allowed access the systems ensures stronger security. You can also place authentication on the LAN before access to the DMZ is even attempted. This prevents allowing complete control over these systems at any given time.
There should NEVER EVER be a domain controller sitting in a DMZ to assist with authentication to these systems. Any information that’s considered sensitive, especially internal data shouldn’t be stored in the DMZ or have DMZ systems relying on it. Authentication within the DMZ systems should be based off either a separate DMZ domain or local access to these systems. There are many issues with both of these, especially when it comes to large DMZs with hundreds of servers, but the ability to have authentication that’s easily changeable without the ability to rely on internal authentication is a must.
Segment within the DMZ
The creation and segmentation of systems within the DMZ also is also something to consider. We should never see a web server that’s also running a database server – a database server should never be in the DMZ. Here’s where we get into multi-tiered DMZs that have backend systems isolated from being hit externally, but yet the externally available systems rely on them for a service. A good example of this is a web server passing data to an application or database server. These should not all be in the “public DMZ” because it’s too risky to keep this data within that zone, but many times we don’t want them installed in the LAN either. This is more of a business decision, but the ability to have these servers accessed by both the DMZ and internally needs to be discussed. The data is too important to be in the DMZ and the placement of these systems needs to be considered carefully since the DMZ systems have access to them.
Read the rest of the story here: