Friday, September 19, 2014

Statistics of a Data Breach (SRC Cyber)

40 Information Security Blogs You Should Be Reading

I'm very humbled to have awarded as one of the "40 Information Security Blogs You Should Be Reading" by There are many others blogs that completely outshine this one on the list and I  highly recommended reading them first.

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.