Xkcd is the QED of our industry. Want proof? Check out Randall Munroe's comic on Password Strength.

Longer phrases trump mixed up passwords every time. "Correcthorsebatterystaple" will take significantly longer to crack than, say, "p@ssw0rd". Given this, you might wonder why the industry has not changed to longer phrases. I blame the vendors. There are a number of apps that I support and websites that I visit that still limit passwords to 14 characters. Moreover, many explicitly for prevent special characters. Software support is a problem.

There are other problems, too. See today's Dark Reading article for the pros and cons of using phrases.

Dark Reading: Passphrases A Viable Alternative To Passwords?

There is a wish among some enterprise users that they could institute phrases, but they're experiencing a technology lag within the software and identity management worlds that stymies the urge.

"One reason (organizations don't use passphrases) is the number of software applications that do not support long or complex passphrases," says J. Wolfgang Goerlich, Network Operations and Security Manager for a midwest financial services firm. "Length and special characters seem to be a challenge for some vendors. Sometimes referred to as technological debt, many IT departments must maintain a suite of apps that have not been updated with modern security recommendations."

I am having some fun with DNS and covert channels over the holidays.

At its most simplest, DNS can be used as a text based covert channel. The DNS client sends the message via a CNAME lookup. The DNS server sends a message in response via a CNAME response. By co-opting this process, any character sequence can be sent back and forth.

What if we need to do more? Say, transfer a file? Or even browse the web? The answer here is text encoding.

Most IT folks would jump to the conclusion that the traffic simply needs to be Base64 encoded. There is a slight wrinkle. DNS CNAME queries only support 63 characters: alphabetical lower case, upper case, numeric, and dash (-). Base64 encoding is out.

The next possibility is Base32 encoding. While not often used, it fits within the DNS RFC and therefore works out of the box.

The disadvantages of Base32 over DNS is packet payload size and transmissions. DNS is UDP and, therefore, may suffer from dropped packets. Further, the packets can only be so long.  DNS host names are limited to 255 characters.

Dan Kaminsky came up with an interesting solution to these problems. He essentially tunneled IP over DNS using Base32 encoding. Such protocol layering handles the limitations of UDP. To increase the size, Kaminsky relied on the EDNS0 extension specified in RFC 2671. He released a proof of concept in the form of the OzymanDNS Perl scripts.

As a side note, the name OzymanDNS had me curious. I did some digging. It is a Watchmen comics reference which, in turn, traces back to an Egyptian pharaoh. Nothing says secret writings like comic books and pharoahs.

Anyways, in sum, covert channels over DNS are practical. With some clever protocol manipulation, binary files and even web browsing can be tunneled over DNS.

I have had some great conversations since Raf Los (@Wh1t3Rabbit) posted his podcast Monday. Much of the talk has been around some advantages that we do have.

Down the Rabbithole - Episode 4 - Effective Small Business Security
http://podcast.wh1t3rabbit.net/down-the-rabbithole-episode-4-effective-small-business-security

First, information security is a scaling problem.

I have a staffing rule of thumb. I have posted it before, but I’ll repeat it. Take the employees, networked devices, and IT support staff. Security is 1 FTE per 1K employees, 1 FTE per 5K devices, or 1 FTE per 20 IT employees. Most security folks that I have talked with fall within this range, whether they work with multi-nationals or mom-and-pop shops.

This applies to my case. I am dedicated 25% to security. I have 250 end users and around a thousand end-points, servers, switches, routers, and firewalls. Luckily we have more than 5 IT folks, but you get the idea.

The scopes of security challenges remain consistent regardless of the scale. But we on the small medium business side do have a few unique opportunities.

Information security pros at the SMB level have advantages.

Reach. There are fewer layers between us and executive management. The board level directives can flow right into our security planning. There are fewer layers between us and line employees. The security controls can flow right into their daily activities. Communications are simpler in smaller organizations.

Flexibility. If you are an army of one, not much time is needed for generalship. Reaction and response can be quicker. Process and procedure can be reduced, in favor of action and implementation. 

Cooperation. Baking security in means getting buy in from the IT operations team, the software development team, the IT engineering folks, the project managers, the business analysts, and IT management. With separate teams, this can mean significant work just to navigate the politics. More time can be spent on implementing and less on negotiating when all the folks are in one team. 

End-to-end. One dedicated InfoSec pro in a company with less than 5K devices can hold the entire network in his mind. Two dedicated FTEs and 10K devices, and you’ll end up naturally dividing the work between each other. Reach 100K devices secured by 20 InfoSec guys, and one person knowing every nut-and-bolt becomes impossible.

A small network can be a very secure network.

Security flaws come from the people creating the security controls in a vacuum with no relation to the organization’s mission. Security flaws come from people working on the front lines, with no ideas of the control environment. Flaws come from projects without security tasks, from systems that go-live without security review, and from bolted-on security features. Flaws and weaknesses crop up in the gaps of responsibility between teams, and between people.

A security pro in a small medium business is in a position to make a significant contribution to their organization.

"Do you think a team of one person has already lost the battle? Straight out of the gate? Does he stand a chance? Does the individual even have a chance?" -- Michael Allen (@_Dark_Knight_)


Have we lost the battle? On the one hand, we say that it is not if a breach will occur, but when. On the other hand, we say that we are all one breach away from unemployment. What does this tell us about the InfoSec field?

We need a seat at the table.

Most of us got into security back when, if you knew how to set the pins on the modem and knew how to type up firewall rules in a text editor, our users thought we were rockstars. They depended upon us. And we, in turn, depended upon their dependence in order to keep things running securely.

That is no longer the case. People today are more tech savvy and more willing to Google it for themselves. A slew of new companies, with buzz words from cloud to IT consumerization, enable the users doing just that. People do not depend on us any more.

Perhaps we became too dependent on their dependence. We no longer get a seat at the table. We no longer have a free pass. We no longer get included in discussions on new technology. And then we become concerned about all the technology being deployed in our organizations without proper security review and controls.

We must earn a seat at the table.

The #SecBiz thread on Twitter represents a search for earning that seat. #SecBiz shifts our focus away from securing technology and towards securing businesses. Less modems and firewalls, more business initiatives and processes.

Raf Los (@Wh1t3Rabbit) has been on the vanguard of this change. From his blog, from his presentations at B-Sides Detroit and everywhere else, and from his podcast, Raf has been driving home the point. This week, Michael Allen and I were guests on his "Down the Rabbithole" podcast. The topic being information security in the SMB space. We had a fantastic conversation about what security means today.

Are you wondering how to get a seat at the table? Feeling like you have already lost the battle? Spend some time following the Wh1t3Rabbit.

Down the Rabbithole - Episode 4 - Effective Small Business Security
http://podcast.wh1t3rabbit.net/down-the-rabbithole-episode-4-effective-small-business-security

Let's put politics aside for the moment and focus in on why so many organization's label their attacks as being sophisticated. What makes an attack appear to be advanced and persistent?

It truly is all about appearances. We have years of data now from threat reports such as Microsoft's and Verizon's. The reports continue, year after year, to show the same basic truth. Most attacks were due to relatively simple things, like misconfigurations or missing patches. Most attacks are not discovered for weeks to months. When discovered, they are cleaned up in a relatively straightforward process. If that is the case, then why would an attack appear advanced?

It is the law of uphill analysis and downhill invention. Valentino Braitenberg coined the phrase in his book Vehicles. The law is one of the reasons an attacker has an asymmetrical advantage over a defender. Like going downhill versus going uphill, it is much easier to implement something in technology than it is to figure out what happened based on the result.

Things generally seem more complicated at first. Think of any recent troubleshooting incident. Pick a particularly stressful situation. Your team is calling you with updates. Your management is calling you for updates. Other business units are calling you to stress the importance of a quick resolution. Your management's management is calling you to check in. With all that distraction, you are trying to piece together what has happened.

Did it seem particularly challenging event? Did it seem almost insurmountable? And yet, I wager, the root cause was something simple. When all was said and done, when the fog cleared, when all the facts were at hand, the problems turned out to be sequence of simple events. Such problems usually are.

The law of uphill analysis and downhill invention is at work in security incidents. More so, too, because here the attacker is actively working to subvert your investigation. Sure, it was just a spearphishing email that planted a backdoor on the network. But at the time, to the people inside, all they knew was that the attacker was seemingly everywhere inside the perimeter at once. It takes quite a bit of time, training, and effort to work backwards.

What do I hear when someone says it was an advanced persistent threat? It was persistent because it took the organization a long time to detect the attack. It was advanced because it took the security team a lot of effort to figure out what the attacker did. The threat is in over exaggerating what it take to defend a network.

Whenever a breach occurs these days, the organization’s management is quick to call it a sophisticated attack. The media’s quick to jump on the Advanced Persistent Threat or APT bandwagon. Then, sooner or later, news leaks that the attack was actually something quite trivial pulled off by regular people.

Take the Comodo attack. The founder is on record as saying "This [attack] was extremely sophisticated and critically executed. It was a very well orchestrated, very clinical attack, and the attacker knew exactly what they needed to do and how fast they had to operate."

Moxie Marlinspike relayed at BlackHat and GrrCon what he learned about the attacker. Turns out the guy surfed into www.thoughtcrime.org and downloaded sslsnif after the breach. Where did the attacker come from? Hak5.

Moxie Marlinspike: "On the one hand, we have the CEO of Comodo. Very well orchestrated. Clinical. Maybe this video was really good. Maybe it turned them into clinical attackers. But, from what I see, on the one hand we have the CEO’s statements and on the other hand we have someone who is literally following video tutorials on the Internet."

Where is the disconnect? The cynical answer is that it is politically expedient to label attacks "sophisticated". Bonus points if you can link the attack to foreign nations. If the attack can be grouped under force majeure, well, who can defend against that? And who can blame the company for falling prey?

That's the cynical answer. Tomorrow, I will share a more pragmatic reason.

For now, I will give the last word to Jack Daniel. "Every breach is sophisticated, just like everyone is special."

There is no patch for stupidity. L-users. Pebcak: problem exists between chair and keyboard. ID10T error. We had everything secure, but then we had to let the users on. We have all heard the jokes.

The problem is that this mindset sets us up against the users.

Corporate security teams need less "I fight the users" and more "I fight for the users". Yes, I am quoting Tron. Here’s a clip with the iconic line:

Tron: Legacy clip on YouTube
http://www.youtube.com/watch?v=vGG5vwH7mm4&t=0m52s

Security teams protect the organization’s mission and profitability. That fundamentally means protecting a user’s productivity. Protecting IT systems is secondary. That is a bit of a mindset shift, I know, but bear with me.

What does it mean to fight for the users? It means viewing IT security breaches in the perspective of the impact to the business's mission. It means viewing IT security controls in the perspective of the impact on user’s productivity. Fighting for the users is central to business-centric risk management.

I was at a family event this past weekend. As so often happens at these events, the conversation goes something like:

Them: "Oh, you are in computer security? I got this virus. What should I do?"

Me: "Uhh … Well, that’s not really what I handle."

Malware infections in the corporate world are easy. First, we keep up on the patches. That prevents a lot of infections. Second, we have anti-virus software with updated signatures. This catches what gets thru. Finally, if computers do get infected, we have a silver bullet. A simple reimaging gets everything back in shape.

People at home are not so fortunate. Reimaging is not a fix for them because that often means losing valuable data and applications.

Until recently, my only advice was to reload. Then Brian @ Select Real Security put up an in-depth guide on removing malware. Now I have a better answer. “I got this virus. What should I do?” Check out this guide.

Malware Removal Guide for Windows
http://www.selectrealsecurity.com/malware-removal-guide

"This guide will help you clean your computer of malware. If you think your computer is infected with a virus or some other malicious software, you may want to use this guide. It contains instructions that, if done correctly and in order, will remove most malware infections on a Windows operating system. It highlights the tools and resources that are necessary to clean your system."

DigiNotar declared bankruptcy this week, following a high profile attack that lead to malicious certifications being issued. Some five hundred certifications were issued, for everything from Google, to Twitter, to Microsoft, to the entire *.com and *.org namespace. Major browsers quickly removed DigiNotar's root from the chain, thus protecting folks from these rouge certifications. And then DigiNotar was no more.

People are already saying this proves that IT security breaches put companies out of business.

I believe that is the wrong lesson.

Let's take four companies with high profile breaches: DigiNotar, Distribute.IT, Sony, and TJXX. DigiNotar went bankrupt. Distribute.IT? Shuttered. Sony is back to business (handling it with an update to their SLA.) TJX is unaffected.

So why did TJX survive? At first, this does not make much sense. But consider the attack as it relates to impact to the organization's mission.

TJX is in retail and has reasonably deep pockets. The attack did not so much as ruffle its ability to sell product. Save for a dip during the fall out from the attack, TJX did not suffer economic harm.

Sony is in the business of providing access to its services. Though the attack was not necessarily about availability, the attack severely affected Sony's ability to reach the customer. They have deep pockets, however, and are making their way back. The reasoning behind the service level agreement and terms and conditions agreements is to minimize the cost exposure of future breaches.

Distribute.IT was in the hosting business. Their job was to keep other companies sites online, available, and protected. The attack was an availability attack that was made worse due to mismanagement of data backups. Distribute.IT, without the cash reserves and without any means to get back to business, was dead in the water.

The attack on DigiNotar struck right at the heart of their business. The mission of a certificate authority is to safeguard certificates and ensure issuance only to legitimate entities. We are talking about reliability and authenticity attacks against a company that markets a reliable and authentic security service. Further, due to DigiNotar's limited reach (fewer than 2% of SSL hosts), there was little risk for the browser makers to remove DigiNotar's root.

The lesson here is security controls must be framed within the context of the organization's mission. Breaches can be weathered if the impact is low or in an area outside the core mission. Security breaches only put companies out of business when controls are not appropriately geared to the organization and when the financial impact is serious.

We kicked off a new Cloud Security Alliance (CSA) chapter in Detroit this morning. The new chapter will be serving South Eastern Michigan. While some groups are geared to socializing and networking, CSA SE MI looks to distinguish ourselves by actively working on projects. With my private cloud operational and my eye on public cloud offerings, I am excited to contribute to body of knowledge.

Watch this space for more to come on securing public and private clouds.