Saturday, July 12, 2014


Onward Through the Cloud

Over the past couple years anything with the word “cloud” in it has been selling big. It's been the ultimate buzzword in marketing and has completely clouded (pun intended) the understanding of what cloud-computing actually is these days. If you ask ten people today to explain what the cloud is you'll most likely get seven different answers. This confusion behind what a cloud actually is has also confused people from a security perspective as to what they should be protecting. If you're not sure what you're getting into with cloud services how can you realistically secure it? In this blog we'll speak about a few of the high points on security while in the cloud.
What’s Driving You To The Cloud?
Before you do anything, you'll need to consider what type of cloud architecture you're going to be building. Are you looking for a public cloud, private cloud or more of a hybrid/bare-metal service? This is really going to depend on a few things. Are you currently under some type of compliance requirements, like I don't know, PCI? If the answer is yes, you're going to find yourself moving towards more of a private or bare-metal cloud offering. It's not going to fly on the public cloud from a security perspective or a compliance perspective, if you're sharing resources with other clients. Also, what will you be putting in the cloud? Are you putting web servers, custom apps, file shares, etc? Depending on what you put in the cloud will determine the type of cloud you'll need, but having a hybrid solution that allows you to keep data separate from other clients in the cloud is the most important security decision you can make regarding your cloud architecture.
Consider The Risks of Cloud Infrastructure
After you've decided what type of architecture you'll be going to in the cloud, you need to consider what type of infrastructure you'll be using. Many people that go into the cloud these days are using shared  resources, not only from a storage and virutalization perspective, but from a network perspective. If you have a private cloud or a bare-metal implementation it's very possible that you're still running on shared load balancers, routers, firewalls, IDS, etc. It's here that you need to consider the risk of not owning your own infrastructure. Will this reduce cost? Absolutely. Will it add an area of risk to your network that you can't control? Absolutely. If you're on a shared load balancer or router and another client is to get attacked with a DDoS, or has greater than normal traffic hit their site, it's very possible that you're going to take a hit on your network due to their issues. This is something which you can't protect and are at the mercy of the cloud provider to mitigate. If you end up using the current firewall that's already in the hosting provider, be careful to review the SLA's of change controls and firewall changes before moving to this type of solution. Even if it's a hosted firewall that you have complete access of, it's going to be hard to run rule reviews on these systems without having complete control. Long story short, be careful to buy into a hosted cloud infrastructure model without first reviewing the risks.
 Security First Mentality
Lastly, from a security perspective you need to understand what you're gaining and what you're losing by moving directly into the cloud. Are you gaining a more solid security architecture by moving to the cloud? Many companies that start off now would be starting from scratch without a current infrastructure and would be wise to review these cloud offerings. Moving to the cloud can enable better security for these companies, rather than buying all the equipment themselves. But for established companies that already have a security architecture in place, they need to determine what's going to benefit them most from a security standpoint. If moving to the cloud means they have to limit themselves from performing security at a high standard, they need to determine how to keep the risk down.  Below are a few areas you should consider before jumping into the cloud (this is only a starter list):
  •  How cloud providers are perform DdoS mitigation? Do you own your internet connections (where there's DDoS mitigation already built in, or do you have to provide a separate service?)
  •  What about IPS and WAF? Will you be able to bring your own, or will you be forced to use the cloud providers? If you do use their systems will you be able to customize them with the rules that you might be used to? Or what about log management?
  • Where are the logs going to be thrown to while in the cloud? Do these providers have the ability to collect logs and run queries on them? If the answer to these questions is “NO”, you need to consider the risk of moving your network to the cloud.
  • Who has physical access to the datacenter while your data’s being hosted elsewhere?Where are the backups stored? Does your data ever get sent off internationally for any reason? The privacy and breach laws are different once data is no longer domestic.
Read more of my article over at:

Creating a Secure Guest Network

It’s inevitable; someone from outside your organization is invited into your corporate headquarters, either for business reasons, professional services, sales etc. and needs to access the internet without one of your standard company issued workstations (GASP!). I’m sure we’ve all been in similar positions, both entering another business and securing your own organization, but how are we to respond? Do we assume that internet access will be given to guests? We’ll at this point in time I think it’s a fair assumption that it would be, but how it’s accomplished from the hosting organization will make the difference. In this article we’ll go over a few ways to empower the business and keep it secure by allowing guests appropriate access to the internet.
There should always be a process involved when making any changes to the network. This includes tickets, change control, approvals, etc. This is just best practice and people looking to have business partners or consultants enter your network should be aware of the process. If it’s going to take a few days to get all the approvals for someone external to get approved access to the internet, make sure you educate them so they give you proper lead time in getting the access and approvals completed. If you don’t educate the business on how YOU want things to happen, don’t be upset when they don’t follow them. It’s up to you to determine how the process goes, so lay some expectation down early.
Before someone from the outside even walks in requesting internet access, we need to have some expectations regarding these guests systems. At no point should you consider one guest as “more secure” than another guest. Just because you’re having a security consultant come in to speak to you doesn’t mean they’re getting access to your internal network. We’re not playing favorites here and everyone coming in as an outsider needs to be treated with the same level of scrutiny. You don’t manage their workstations, you don’t know where they’ve been, what malware’s lurking on their laptop, or for that matter, what they’d do to your internal network if given the chance. Long story short, don’t trust them; no matter how nice they seem, or what their role is.
Now that we have the approval process and expectation of security in place, we can start building the infrastructure to protect your internal network from these guests. Here are a few steps to accomplish this:
  • The first thing we need to speak about is segmentation. Since most of the requests are will come from guests using laptops, I’m going to assume they’ll be asking for WiFi access first. One of first things that need to be done here is the creation of a guest WiFi network. One way this can be done is by creating a separate SSID for guests that terminate on an isolated VLAN and go out to the internet segmented from your internal networks. The goal here is to keep them isolated. The internet access can go directly out your corporate outbound internet connection, if it’s segmented, or you can have a separate circuit (DSL, cable, etc.) installed, which completely removes them from egressing out with the remainder of your internal employees. Either way works fine, just as long as they’re segmented. Make sure you firewall policy enforces your segmentation. (The latest release of the AlgoSec Suite can really help here)
  •  Access to the guest wireless should also be locked down. Not everyone within range of the access point should be given free WiFi out of your network. Your network should be locked down with at least WPA2 using passphrases which are used to authenticate guests to the guest wireless network. Creating a captive portal with a user account that was created during the approval process is ideal. Each guest user logging into the portal with guest credentials to the wireless network will be logged. It will also help with creating timeframes of approved access to the WiFI network and removal of user accounts after a predefined date. It’s important to control the access to the WiFi network in order to police who, how and when a guest can connect to your network. Access should also be removed once the guests no longer need it.
  • Monitoring the traffic on the guest network should still be done, even if they’re not on your systems or hitting your internal networks. In the greater scheme of things, this is your network and you don’t want anyone doing something nefarious to other guests, trying to do something illegal from a network you own, or have malware spread to others connected to the same network. This network can be a little hairy at times, but we should still keep an eye as to what’s happening on it. Installing an IDS/IPS on the network after the traffic’s terminated into the wired network is something that needs to be done. You need to know if you see traffic sourced from the guest WiFi network that’s doing something evil. Even with segmentation in place, you need to know what’s going on. You should also put some type of web filtering in place on this network. Just because they’re guests doesn’t mean that they get full access to the internet from your network block. Remember, the world is going to see this traffic sourced as your company, not as the guest that’s sitting in your company. Don’t get yourself in trouble by allowing them to browse every site under the sun. You can put a custom policy in for your web filtering based off the guest WiFi network, but don’t just leave it open.

Integrating Threat Intelligence Into Your Security Program

When it comes to securing your assets you need all the help you can get and it’s about time we realized that we’re not in this alone. Many other security teams are in the same boat and we need to stick together when it comes to defending our data and infrastructures. We’re in a constant arms race with the bad guys who have been known to join forces and attack a particular group/organization to fulfill their evil agenda. With the bad guys working together and sharing information, why can’t we? This is why threat intelligence has become such a burgeoning new market. Once we grasp the fact that we’re not in this alone, we can start understanding that there’s the possibility to share our resources to help defend against the other side.
What is threat intelligence? That’s a great question. Depending on whom you ask right now in the cyber community it could mean five different things to five different people. In a nutshell, it’s the ability to have actionable data about an attack/attacker, so that you can make an educated decision on alerts and incidents. This actionable data is a great starting point to understand if a particular alert or event has been seen by someone else in the infosec community. Let’s consider Edward Waltz’s statement on intelligence and how it’s used, “information and knowledge about an adversary obtained through observation, investigation, analysis, or understanding, is the product that provides battle space awareness.” Armed with this intelligence allows us as defenders to make stronger decisions and focus on alerts or incidents that we might not have reviewed without it. Now that we’re familiar with what intelligence is used for at a high level, let’s discuss this in more detail and how it can be used operationally.
There are many startups right now that are offering threat intelligence services, but as we discussed earlier, the gist of threat intel is having data ahead of time to compare towards events and give you a “heads up” on issues that should be reviewed (actionable). Each company does their threat intel discovery different – some are setting up honeypots, scouring the web, performing research and purchasing the information from other vendors or researchers. This way is fine, but I think in the long run we’ll get a higher level of confidence in threat data that people are willingly sharing to a community. By allowing services to anonymize the data and that’s entering your network will give the intel community a more focused view on intelligence. Even to the point of having intelligence by sector so that if the same attackers are looking to hit the same sector again, you’d be notified. I’m sure if you were in retail you’d be very anxious to get the data and alerts from Target in your possession. This shared community, where people are not only using the information in the community, but actively contributing to it, is where we need to get to as cyber defenders.
Now that we have this intelligence thing down how can we make the best use of it? What’s needed is for this intel to be integrated into your currently installed defense systems. This can come in the form of feeds from the provider that are streamed into your equipment, downloaded or manually uploaded. You’re looking for the quickest way to have the intel inserted into your equipment so that you have the actionable data at the ready. A few systems that allow these data feeds are IPS, firewalls, log management, SIEM, web filters and mail gateways. These are the normal places you’re going to use this intelligence to compare against IOC’s (indicators of compromise). These IOC’s (virus signatures, IP addresses, hashes of known malware, URLs of phishing sites, etc.) can be used as an early warning of attack against your systems and a sign of future attacks. As an example, tying the threat intelligence into your SIEM will alert you when an IP address in China, which was recently used in an APT attack against another company, is port scanning your DMZ. This intel will not only show what attacks are occurring, but what the motivation is of the attackers. If this IP address has been seen performing DDoS attacks and holding sites for ransom, it’s a good bet that they might be looking to do something similar. By combining your current data with the threat intelligence will give you a better understanding of what the ramifications of these events might be. Going back to our example, many times you won’t think twice about a simple port scan, but when you know who’s behind it you might want to make adjustments. It’s all about the intel, baby.

The Impact of Red Team Drills

Practice doesn’t make perfect it… it makes us better at something. If we’re not hardening our craft and finding our weaknesses we’re doomed to fail. This is why athletes put in time at the gym, review old game film and focus on opponents’ tendencies. It should be no different when it comes to information security.
As information security professionals, we need to take the time to practice drills regarding our dreaded security breach scenarios. We need to understand our vulnerabilities and security weaknesses before they’re exploited. It’s much better that we find the soft spots first, instead of an attacker doing so for us.
This is why “red team” drills are so valuable to an organization trying to protect their assets. Many people in information security are very interested in “pushing buttons” and leave the soft skills out. Without running red team drills, you’ll never know if your technology is working. These are the tests that put the rubber to the road and many times prove that there’s quite a bit of improvement to be worked on. Here are a few examples of red team drills that might be of interest.
  • Test Your Systems
    Many companies overlook, or at least water down, the dire need of penetration tests. Having a skilled white hat in your network showing you what an attacker can do is like giving you a crystal ball. These people are invaluable to your security posture. If you’re large enough to have a full time pen tester or if you’re hiring them when needed, they will show you things that make your jaw drop. All the confidence of the work you’ve done securing your network will quickly go out the window. Make sure you do your homework when hiring someone to attack your network. They will essentially have all your dirty laundry and you wouldn’t want that information in the hands of an inexperienced pen tester.
  • Attack Your Users
    The largest point of weakness in any company is the people that work for them. These people need to be educated, of course, but how do you know if all the hours spent with security education was absorbed? We test of course and this happens to be my favorite part. Creating phishing emails to see if the users will click on them is a good test. USB/CD media drops around the building with beaconing software helps determine if they’re following instructions about not putting random media in their workstations is another. But the best type of test is when you can actually speak with end users. Calling into call centers, or getting the name of someone off social media that works in the finance team is always a good bet. Here you can determine firsthand if they’re following procedures and give you better insight into further education training that is needed. Impersonating what an attacker would do and how the users respond to these types of attacks is great data to have in your metrics and toolkit. This is a must that is often overlooked – educate your users test them too.
  • Live Your Nightmare
    Picture the worst thing that could happen to you as an information security professional. Maybe you wake up one morning and hear that all of your customer data has been exposed. You’ve been owned, now what. We’ll if this wasn’t already thought of, you’re starting at ground zero in the worst possible case. If you have procedures in place to stabilize the destruction, you might still be able to weather this storm. Creating a list of incidents, both internal and external, to your network will give you a starting point of where to start breaking out your scenarios. After you have your top nightmarish issues, bring people from all over the business and discuss what they would do? For an example, if customer data was found on a website based in a foreign country, what would marketing do? How are they going to handle Twitter responses to your site? What will customer support say when angry customers call up asking about their data? How will the internal investigation occur within IT? Who will lead this effort? So on and so forth. Without having these ideas and scenarios worked out already you’re going to be in a lot more trouble than you might think.
Read more of my article here: