Wednesday, November 19, 2014

The War Against Personal Privacy

With the recent revelation of FBI director, James Comey, attacking tech companies for allowing complete encryption on their mobile devices, we as citizens should be concerned with our liberty and freedom; not just our privacy. When a government official thinks we as a people should lower our security and privacy standards because it makes his job easier to catch criminals, we should all be on our guard. If this is the case, I might as well leave my home unlocked, because if I was to get robbed it would make it easier for law enforcement to enter my home and catch the thieves. This of course is ridiculous and there are ulterior motives involved that include snooping on American citizens. With recent allegations and court hearings being brought up against our government due to citizen snooping, it came as a surprise that Director James Comey would come out so boldly with these remarks. This to me shows that our government doesn't care about our privacy and are still barreling down the path of complete control, with limited oversight.

Privacy is liberty and when it’s slowly siphoned away from our individual rights, so is our liberty and freedom. This is something that’s been happening for decades, with the FISA courts, PATRIOT Act, NSA warrant-less surveillance, etc. and with each legislative power grab by the government, either under the guise of security, the fight against global terrorism, the protection of our children, we end up handing over more of our God given right that our founding fathers fought so hard to establish. James Madison understood these issues when he proposed the Bill of Rights into the constitution; he understood that an individual has rights that a government shouldn't be infracting upon and that by pillaging these rights away from citizens will weaken not only our individual freedoms, but our collective rights as Americans.     

Why does the government want us under such high surveillance? It might come as a surprise to some, but just because you’re a government doesn't automatically make you trustworthy. There have been multiple occasions in history where regimes have controlled their inhabitants by the ever seeing eye of surveillance. We must learn from these mistakes in history now, so that we don’t repeat them again for our generation and generations to come. Even if a government was doing something honorable with mass surveillance doesn't mean that over time it won’t change its ideologies for something more nefarious. Once power has been given, once control has been handed over, it becomes orders of magnitude harder to withdrawn and rein that authority back to what it once was. Governments are aware of this and are consistently using fear and uncertainty during times of crisis to influence the actions of lawmakers and citizens to snatch more power. The best trick a Government can play during a crisis is making its citizens believe that it was their idea to include mass surveillance.

Why, then, is Director James Comey terrified of encryption? This isn't a new thing either. The Government has had a long fear of encryption, not really a fear of cryptography, but a fear of not knowing is more of what they’re concerned with. This goes back to the early nineties when the Government threatened Phillip Zimmerman, an amateur encryption enthusiast, with potential prison time after creating PGP. Not only was he being threatened, but he was being charged for being an “arms dealer”. Is this what the Government see’s encryption as? A weapon?! Encryption isn't a weapon, it’s a shield and we as citizens have a right to protect ourselves from mass surveillance. It’s not a war against crime; it’s a war against personal privacy. 

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.

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:

Tuesday, April 8, 2014

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

Following up on my last post on ensuring network security when working with third party vendors, to wrap up the discussion, we must examine data access levels, your incident response plan and the concept of cyber-insurance. Having an understanding and a plan around all of these can help you mitigate weak links in your security chain.
  • What Data are they Getting and how are they Getting It?As part of this process you need to find out what type of data is being sent to the vendor. Many times other parts of the business will not find an issue with sharing a database or giving all your client information to a third party, but you should. Be aware of what’s being sent to these vendors and limit the PII and credit card information from being sent over to them. The more you review here the less risk you’ll have going forward. You don’t want another company having credit card numbers and then losing them. Let’s find out up front what they’re asking for and determine the safest way to provide them with what they need. If they want more information than you think they really  need, you might want to choose another vendor, or at least ensuring  a secure method of access to what’s required. Once this has all been vetted, you need to determine how the data or access will be obtained by the third party vendor. You’re in control here and it’s up to you to determine the guidelines as to how your data will be sent over to a third party, or how that third party will access your network.
    • Network segmentation folks.  When accessing your network, there should be a separate segment for vendors. If a vendor needs to access your network for some reason, treat this access like a DMZ. You have a separate firewall with monitoring enabled looking for suspicious and malicious traffic. They should only be accessing your network via a VPN with some sort of two-factor authentication in place. Monitor the accounts being used and verify that the passwords are long enough that a dictionary attack isn’t going to catch them, normally stay around 15+ for the character limit.
    • In terms of data transfer, don’t allow any data transferred via an insecure protocol. Many vendors still ask to have data transferred via FTP and this should be stopped. If you’re still using FTP to accept data as a vendor the probability that you’re not following other basic security practices is high. Always have a secure method of transmission for your data while it’s being sent, remember it’s your data.
    • Make sure that the data being sent is encrypted so that if the vendor’s storage was compromised or not secured appropriately, it will be encrypted-at-rest. This might sound like I’m being paranoid, but this is the lifeblood of your organization and you don’t want this falling into the wrong hands.
  • Incident Response PlanNow that you’ve vetted the vendor, determined what data they need and how it’s going to be transferred, you need to start thinking about worse case scenarios. If you’ve done all of the above, you’ve done your homework and due diligence to protect your data. Even so, there’s always the possibility that data is going to be lost or stolen. Knowing that this is always a possibility you need to come up with incident response plan focused around your third party vendors. Bring in all areas of the business and live your nightmare [insert from Red Team drills article]. If you have a security breach you need to be prepared to work with this vendor to coordinate what happened to your data, who must be involved and what steps need to be taken. Having role played this before an incident with the proper people understanding their role and appropriate documentation created will help get a jump on controlling the incident… before the incident controls you. You can even speak with the vendors themselves about your plan and what you expect from them during an incident where they’ve lost your data or access. The more planning the better.
  • Cyber-insuranceSo you’ve done everything here and realized that you still had a breach. The IR planning went well and you were able to contain the incident quickly, but you still lost a great deal of money. This is where Cyber-insurance comes into play. Having purchased insurance before a breach occurs can save your organization millions of dollars in lost revenue. Just like any other insurance, it doesn’t really pay until you need it. It might be a hard sell to some businesses, but in the long run if you have millions, or even billions, of dollars at stake, it’s going to be beneficial for you to purchase some type of insurance. This will not help with the reputation damage that will occur from a breach, but it will assist with keeping some of the cost down.

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: