Safe to Deploy? What’s That Mean?

June 24th, 2010

 

Over the past several months, I have spent many days in the lab performing Safety to Deploy (STD) tests on our customers’ products.  Let me tell you, this has been an enlightening and immensely educational experience.  If you’re not familiar, the Safety to Deploy test is the first in our trio of tests designed to improve product development. STD is the initial pass with a high level security approach focused on a single typical-use case of the product.  Further tests (Fit for Purpose is second in the series and the Destructive Test is the third) are designed to push the security limits and dive deeper into validating product claims.

 

Many of our customers are in the security industry so we’re often asked to focus on their security tools or products. The TSC tests are not quality assurance tests that look at what the product engineers designed the product to actually do, although that can be a part.   The Safety to Deploy test looks at the product from the perspective of a potential end user or systems administrator and considers whether, under typical use, it introduces any security or business risk into the environment.  This is almost an easy answer:  Unless the product is replacing an existing tool and making things more uniform or simpler, it naturally adds risk – it’s another vector for vulnerabilities to be introduced; it adds more complexity into the user’s world.   We all know that these things introduce risk.  But these aren’t the kinds of things our Safety to Deploy test evaluates; instead, we assess whether the product unintentionally adds more risk than the benefits it provides.  In other words – is it something TSC would recommend be deployed in a network or on a system?  If not, what needs fixing and how should it be fixed?

 

The TSC team thinks about a wide variety of concerns while going through this exercise.  My colleagues and I brainstorm all the ways that things can break and how malicious attacks or unintentional mistakes may cause either system or configuration failures.  Will I be able to deploy it?  Is it easy?  Could I accidentally leave holes in the security when I do so?  Can someone get to the configuration and deliberately or accidentally change it?  There’s so many of these questions that I could take pages to enumerate them.  Many of them are dependent on the kind of product it is and the complexity.  Fundamentally, though, remember that this isn’t a hacking exercise.  I’m using the team’s collective experience to understand where failures can be introduced and looking to see whether, indeed, they have been introduced.

 

I’ve tested products where everything breaks.  Believe me, this is not a day to be in my office.  Even I don’t want to be there.  It’s hard to keep going when you get frustrated trying to get the product to run!  Fortunately, there are the opposite days, too, where you get a really sweet product that works the way you expect and has a great user interface and clearly had smart people working on the design.  Strangely enough, I’ve seen products at either end of this spectrum–from the same development teams.  Our goal is to help our customers consistently turn out great products every time!  [Or maybe just so I don’t have those nasty days in my office! ;-> ]

 

The end result of our Safety to Deploy testing is a packaged document that considers the product, the typical environment, and the business and security risks that can be introduced in a standard deployment; we also provide recommendations on how to improve the development processes to make them more reliable.    I think the TSC customers definitely get their money’s worth.  The recommendations that come from the team are sound, based on strong business acumen and years of security, operations, and development experience.  I haven’t had a dissatisfied customer yet…

 

 

iPad my web security recommendations…Not!

June 11th, 2010

Sometimes this is just too easy! In my last post I whined that AT&T has pushed testing to the back burner by imposing a penalty for bandwidth-hungry applications. I postulated that they would create a situation where app creators would cut corners in order to cut bandwidth requirements, all in an effort to entice customers to buy their applications. Well, how can we expect the application writers to be security-conscious when AT&T can’t even toe the line?

 

Come on, a basic web application flaw was discovered that allows attackers to extract email addresses by looking at the protocol that iPad uses to query the AT&T network about a customer’s data accounts. This was an effort to make it easy for iPad owners to stay within the limits of their account fees. The “researchers” discovered a basic flaw that would have been obvious to anyone testing the application.

 

Granted, all it did was reveal email addresses but come on! A review of the protocol and a few simple tests would have revealed this before the site went public. I have to ask if this is the kind of reasoning that the developers at AT&T are using. The question is, what other kind of protocol failures can we expect to find as we move deeper into mobile land?

 

Some references….

 

http://news.yahoo.com/s//nm/20100611/tc_nm/us_att_fbi

http://www.examiner.com/x-46117-Long-Island-iPad-Examiner~y2010m6d11-FBI-probes-hack-of-ATT-accounts

 

Smashing Butterflies

June 11th, 2010

I know you’ve seen the old science fiction B movies where the hero warns the antagonist that they should be careful because killing one butterfly in the past could alter the future in ways that can’t be imagined. But somehow the antagonist winds up smashing some poor defenseless butterfly and the hero has to figure out how to keep the world from plunging into some kind of history-induced destructive death spiral.

Well, that butterfly was smashed flat last week by AT&T and it’s going to alter the future for us all.

Last week AT&T announced that unlimited data was going the way of the Dodo, the Newton, and CPM. So why would AT&T change their policy especially in light of the new iPhone release and the iPad – both devices that are reliant on wireless connections to make them useful?

 

Survival and market perception.

 

Although there were only a few people that have been stressing the AT&T network, all of us have been able to feel it. AT&T knows that the number of bandwidth-hungry applications has been growing and would continue to grow as long as people didn’t have to pay the consequences – i.e., pay AT&T for the bandwidth that they’re using. So, in an effort to stave off the complaints and competition, AT&T decided to use behavior modification instead of technology to solve their problem.

 

Is this bad? I think so. Why is this bad? Well, to start with, the unintended consequences of smashing a butterfly flat.

 

In this case, the butterfly represents the present mobile market trend to just move larger and larger chunks of data. More video, flash, and even mobile devices designed specifically to replay television and movies have impacted the data network and created some pretty interesting support issues for AT&T as well as the mobile device and mobile application vendors. Who do you blame when you can’t watch the latest episode of Stargate Universe because the network has wedged? AT&T doesn’t want to hear it! Ignoring the obvious issue with charging more for more bandwidth (like, what’s my SLA buddy?) the application writers are going to have to think of a clever way to circumvent the band-limit controls in an effort to convince customers to buy and use their bandwidth-hungry applications. How is this going to be done? I’m not sure, but I wager the solution won’t enhance the security of those applications one bit.

 

At TSC we’re seeing more financial industry companies shoehorning their services into poorly architected and quickly written mobile applications that are tending to support smaller and smaller financial transactions. Some folks are getting on the micro-transaction bandwagon even as you read this. Sure, the amounts for each transaction are smaller, so you’d need a lot of them to make any money, but when there are billions and billions of them the pennies add up rather quickly.

 

So there’s this kind of schizophrenic behavior: on the one hand we have financial transactions that are moving to smaller sizes while the things that they’re buying are getting larger. A one-hour TV show for less than a dollar will generate a huge amount of data. For most people, you could chew up your monthly data allotment with less than two Stargate episodes. Perhaps that’s what AT&T is counting on – that folks will opt in for the cheaper plan and then pay the horrific penalties for overages. I personally find it hard to believe that any company would intentionally try to use human nature for their own fun and profit, but what do I know?

 

So where does this take us? Down a dangerous path because in their haste to meet an evolving market demand (more stuff for less bandwidth) application vendors are going to cut even more corners. We’ve seen in the past that the Big Guys are less inclined to ensure that their services are bulletproof than their smaller competitors are, so we’re going to see more security holes. Now they have a business motivation to cut even more testing corners.

 

So I guess that makes the score Butterfly Smashers 1, Future Security 0.

Ponzi Schemes, False Trust, and PCI QSA

April 4th, 2010

In this land of phishing attacks, root kits, and ponzi schemes, it doesn’t surprise me a bit that the PCI QSA program has gotten as much traction as it has. Just so you know, I’m setting the rant bit to “on” here.

As a point of reference, a ponzi scheme is a fraudulent investment con that uses the investments of previous investors to pay returns to new investors. Ponzi schemes entice new investors by promising fantastic returns on investments that other investments cannot guarantee. The perpetrator of a ponzi scheme makes his money by scraping profits from each investor. When a ponzi scheme collapses, it’s usually a big surprise to most of those involved. But ponzi schemes do have their whistle blowers. You just have to listen.

Just ask Bernie Madoff.

For those that aren’t aware, QSA or Qualified Security Assessor, is a rating that the PCI Security Standards Council assigns those organizations and individuals that pay them some money and then take a relatively simple test. It is supposed to indicate a level of competency in the science of security assessments that meets the “rigid” requirements of PCI DSS. And, I’m here to say, it does! Unfortunately, those “rigid” requirements of PCI barely rise to the level of mediocrity in my opinion.

Lets take a step back and examine outcomes. After all, the true test of a solution is how well it works over time, no? Well, if we look back on the major breaches of the past few years we see that virtually all the successful attacks were against networks that were PCI QSA certified! How can this be? Well, there is an answer…

To start with, PCI segregates networks into two parts: the part of the network that sees cardholder data, and the rest of the network. Think of it as splitting your network into the mediocre security part and the rest of the network. Why mediocre? Because security can’t live in a vacuum and that’s what PCI expects to happen. They assume that there are weak trust relationships between the PCI relevant systems and the rest of the network. They don’t take into account how code is being generated, tested, published, and updated. They make assumptions about the rest of the network that connects to the PCI relevant systems that may not be true. They take on faith that the rest of the network is secure. There is a very false sense of trust in a very relevant portion of the problem.

QSAs also don’t take into account the drive by the customer to keep the QSA testable part of the network as small as possible. Why? To keep costs down. QSAs earn their money by testing your network and the more stuff they find the more money they make because you have to get more testing done. I suspect that there are some QSAs out there that try to keep the size of the PCI relevant network small because it helps with the bottom line. If you can charge a customer $35K to test 10 systems that’s a better profit margin then having to test 25 systems. Any way you look at it it’s a partial answer to a question that requires a complete solution.

If you don’t believe me, go back and look at the legal documents that outline your engagement. I bet that there are at least a couple of places that absolve the QSA of responsibility for the outcome of the test based on the “completeness” of the information provided.

Add to that the additional issues posed by security exposures that are caused by problems with processes and procedures and you have an interesting problem.

Mathematically, the inefficiencies in your network are multipliers of each other. For example, if your QSA security assessment only covers 15% of your network and only 5% of your people are trained, that means that 95% of your people are potential exposure points. Since people run and use the network, you can treat them as efficiencies. When you multiply .15*.05 you get .0075, or less then one percent efficient. It’s no wonder that security fails.

And when the system fails and cardholder data is exposed people are surprised!

So why compare QSA audits to ponzi schemes? Because each time someone is convinced that they’re investing in their future by using a QSA, they’re investing their trust in the people that had QSA audits before them and, unfortunately, when they’re breached they’re greatly surprised.

To me, this is a very loud whistle.

So, what’s the solution? Granted, this is my blog so I’m going to talk about why I think our solution is better then those provided by QSAs. What you need is a Cardholder Protection Program (CPP) that is part of an Information Protection Program (IPP) that examines your entire network holistically and in real-time. When there is a change in one, you know that there’s an impact on the other so you can take appropriate action. Granted, that action may be to ignore it, but at least it’s a conscious decision and not one based on false trust like PCI.

Googleland!

February 22nd, 2010

A few days ago I sent out a tweet about an epiphany I had regarding Google. Why isn’t Google considered a utility? I think I know why but let’s start here: they’re considered part of the critical infrastructure, Google affects most of the world population, and Google can affect the events of governments and political relations. So, what part of this should continue to go unregulated?

Let’s go through a quick recap. Google produces a search engine that collects huge amounts of information from the Internet, scrapes personal information that it makes available to the government, creates web-based applications that more and more people are using to exchange sensitive information, and their assurance program still sucks. They’ve had outages and their license agreement absolves them of any responsibility or accountability. I should point out that after their last outage they did apologize. Good for Google.

Back to the recap: world reach, unrestricted access to worldwide data, and the ability to screw with governments and people. Hell, Google’s not a utility, Google’s a country!

From what I’ve heard, Google has its own brand of internal politics, there’s infighting and maneuvering and the result is poorly engineered products and bad decisions. Yep, I’m thinking Google’s a country. A self-interested country that’s not really concerned with the impact of their decisions, but a country never the less.

I remember another business/country: Ma Bell. It’s time for the US Government to sit up and take notice. They missed their chance with the Savings and Loans, Microsoft, and most recently Big Banking. When they miss we pay.

I think that it’s about time for the government to recognize the fact that information is just like power, water and sewage. It must continue to flow but in a way that’s beneficial to the public. After all, governments are supposed to be by the people and for the people, not the other way around. I think that Google’s lost their way and may need some gentle prodding by the government to remind them that they’re not to do any evil – even if it’s unintentional evil.

The 4 Horses of the Cyber Apocalypse

January 31st, 2010

OK, calling it the apocalypse may be a bit alarmist – unless you’re a victim of evolving cyber crime. It’s really sad when it’s the very government and utilities that you rely on for live giving services that work erode your privacy and security. So, four events occurred to spur me on to write this entry. I didn’t connect the dots until recently. Few things scare me but this situation is one of them.

The first event: A few weeks ago there was a knock at the door at home. When I answered there was a well-dressed young man with a clipboard and a very official looking ID and permit hanging from his neck. He introduced himself and said he worked for a local alarm company called ABC security. I told him I had an alarm and the next question shocked me: he asked me if I knew which of my neighbors didn’t have alarms! He said it would save him a bunch of time instead of going door-to-door. I told him that all my neighbors had alarms and bid him good day. The door wasn’t even closed before I was speed-dialing SJPD. When the cops showed up 10 minutes later there was no sign of my well-dressed sales person. That was a few weeks ago.

The second event: Early last week one of my neighbors approached me while I was unloading my car after a session of Death-by-Costco. She was very serious and obviously very agitated. She kept looking around as if she expected to be followed. Once I heard her story I understood her agitation: her house had been burglarized the week before.

The third event: Last week the Silicon Valley chapter of the ISSA had their monthly meeting (3rd Tuesday of each month) and at the end of the meeting one of the members quite angrily wanted to know why industrial security wasn’t on the list of important security trends for the chapter in 2010.

The fourth event: I got a notice from PG&E that they were going to install a smart meter on my house and that if I had an issue with it that was too bad. OK, they were “politically correct” when they said it but how many ways can you say “tough nuts”?

So what’s the connection?

Allow me to digress for a bit. Back in the pre-Internet days, when someone wanted to steal your identity they had to do a lot of legwork. They had to research people, family, friends, jobs, life and death, and it took time. A lot of it. Now, criminals can take advantage of aggregated information and stealing identities has become a small criminal industry within the greater scheme of Internet crime.

Getting back to my well-dressed perp, he was casing the neighborhood and relying on the good nature of people to collect information about their neighbors. He took his information and used it to craft a burglary plan that, after 8 break-ins, seems to have been pretty successful. Even in light of the fact that there are photos of the perps and their car, SJPD has yet to apprehend a suspect.

Now toss in the anonymity that the Internet supplies, shake in a few network and application vulnerabilities, sprinkle in a few million smart meters, and you have a recipe for more disaster. Smart meters are those meters that the power companies are trying to install on peoples homes to control power usage during high peak loads so the ancient and neglected power grid doesn’t collapse during said high loads. The advantage to power customers, according to the marketing, is that they can track their usage over the Internet! Yay! (That was the criminals cheering BTW)

Now criminals don’t have to risk getting caught on the streets, they can case your house from the safety of their criminal lair! Or their parents house…or where ever they’re living.

TSC analyzed an RFQ from a major power supplier regarding smart meters and the supporting infrastructure and came to the conclusion that power companies still don’t have a clue about security. It’s the next step in the chain of cyber crime – remote casing of your home using the very web sites that the power companies are using to convince customers that smart meters are a good idea.

I’m upgrading my alarm tomorrow and then I’m calling my power company to tell them to get their security act together. Perhaps you should too.

Password Authentication Takes Another Poke In the Eye

January 19th, 2010

On January 4th as reported on DarkReading and DataBreaches, Lincoln National Corporation notified the New Hampshire Attorney General’s Office of a major security breach affecting 1.2 million people. In addition to the internal cost of investigating the breach and bringing in an external forensics team; in addition to planning and executing remediation activities; in addition to the brand impact and loss of trust in the marketplace, Lincoln National had to cut checks for identity and credit monitoring services for all affected users.

So, was it the theft of vast swathes of personal data? Was it a parade of credit card numbers marching off into the distance? Was it, the now so old school, three men wearing ski masks scurrying out the rear entrance carrying bags with “Loot” written on them?

No. It was that some of their system users were caught sharing passwords. This is a classic “cautionary tale” ( as your grandmother might have said) about how users making poor choices about security issues can impact a corporation in a real way.

So how can you defend against password sharing? Assuming that you already have a policy that prohibits it, I think there are three vectors to consider:

  • Training and education
  • Making non-compliance difficult
  • Monitoring and detection

Clearly, people have to be trained to know that they shouldn’t share passwords. But there are several problems that make this ineffective as the main defense. First, most people don’t care and so will forget. Many users will just not understand or even make the mental connection between what they were told was unacceptable and their subsequent errant behavior. Second (and my favorite), is the common case where people know that it is not allowed but do it anyway in the belief that they are saving the company from itself by ignoring policies that obstruct efficient business operations. You can try either carrot- or stick-based initiatives, but ultimately anything that absolutely depends on users making smart choices is doomed to failure.

So make non-compliance hard. The most obvious solution here is multifactor authentication (MFA). If logging in requires a password and a physical token of some sort (OTP or PKI certificate for example) or some other second factor that cannot be as easily shared as a password, then you are starting to protect people from their own poor judgment. Though I am generally skeptical of the value of password lifetime limits, this is one case where they do help. If the password must be changed every month, then sharing it with others can start to become a burden as the improperly credentialed users need to find out what the new value is from the original owner repeatedly.

Monitoring and detection can be hard to do. It is possible to describe scenario details that a system could use to distinguish valid use cases from people with shared passwords, but they are complex, difficult to implement and subject to many false positives. If a user logs in from two IP addresses within a short time window, that could be a bad thing — but it might also mean they moved from their desk to a conference room with their laptop and switched to using a WWAN link. Geolocation helps…until people go on a business trip. This begins to feel more like an exercise in fraud detection with the consequent vagueness and probabilistic results that you get in that field.

Another concern here is when you want to protect passwords to systems that you do not actually manage. For example, financial services companies often form partnerships and supplier relationships that entail their staff logging into an upstream provider’s system. If the people who want to enforce a password policy do not have direct command and control over the systems in question, it seriously impacts their ability to implement MFA or monitoring solutions.

Bottom Line: Authentication Proxy

So really, the ideal solution is some form of authentication proxy. Allow the user to authenticate locally where you have control and then assert their identity to the remote relying system. This means not letting the user know the password to the remote system. Once they have logged in to your satisfaction locally, the system enters a password into the remote system on their behalf. If the technology components used are mature enough, they may support SAML assertions or such-like to do this gracefully.

This approach gives you the control to enforce MFA and monitoring locally and to leverage that value on remote systems. Then you can just outlaw all passwords that are not managed by such a system and perhaps even watch for those at the perimeter in some cases.

Life, the Universe, and Howard Schmidt

January 11th, 2010

It’s nice to see the potential for things to go right. What I’m talking about is the appointment of Howard Schmidt to the position of U.S. Cybersecurity Czar. Now, there are those out there that think that this is a bad move. I happen to disagree and I’ll tell you why. When I first met Howard he was at Microsoft preaching the gospel of security to folks that didn’t seem interested. But he kept at it and we see the results today; Microsoft has a software assurance program that is slowly making headway.

Howard understands that innovation, hard work, and patience are the main legs on the success tripod. You’re probably saying “innovation and hard work sure, but why patience?” Because when you’re dealing with large organizations if you don’t have patience you go nuts. And I can’t think of a larger organization then the US Government. Yes, it’s even bigger than Microsoft.

There are those that say that Howard wasn’t the first choice and I understand why. The way the job is presently structured, Howard has a lot of responsibility and little authority to get it done. It takes a brave person to step into that breach. Add to that the politics in D.C. and the fact that you have to make a lot of people happy at the same time and it gets complicated in short order. Although Howard will politic, he will tell people what they may not be ready to hear and he’ll use new and innovative methods and tools that may make some nervous. I say good.

Howard is up against a pretty tough rock, right next to a very hard place. There are legacy systems as well as legacy politics at work here. There are places that have to be fixed that the public isn’t even supposed to know exist, but if they fail, we’re in deep dark trouble. But Howard is in a unique position to take advantage of technology and processes that only someone with his unique experience in the public and private sectors can have. He’ll know what will work and how much time it will take for the solution to percolate to success. I trusted Howard enough to write the forward to my book Endpoint Security, and I trust he’s smart enough to write a plan that protects the cyber interests of the U.S. Government and in doing so the people of the United States.

I believe that the Universe took a turn in the right direction last month. I’m going to sleep a little better tonight. The only thing that may keep me up a little bit is whether Obama is going to give him the actual authority to get it done.

Chatting with the CTO of Intelliden

December 14th, 2009

So I was talking with the CTO of Intelliden (www.intelliden.com), a guy named Glen Tindal. I spend a lot of time talking with folks trying to understand what’s keeping them up at night and what’s working in their environments. Sometimes, like this chat with Glen, it’s just about why things are still broken. So it was with some surprise that as I listened to Glen talk that I heard my very words about how the network and the endpoints need to work together instead of the present, almost adversarial, model of two technologies that happen to share the same network space. Our discussion got a bit more specific in that we discussed how the OS and the underlying network need to cooperate in a more seamless manner. In the interest of full disclosure, Intelliden has a product that combines information from network objects into a central management console. (No, TSC hasn’t tested it so I can’t comment on it but Glen seems like a sharp guy.) Glen asked me if I thought there was a company poised to take advantage of an integrated network/OS environment and never being at a loss for opinion, I told him. (If you’d like to know feel free to email me) He was surprised but he had formulated a similar answer – just with different players.

The bottom line was that we both agreed that a couple of major players are going to have to merge their solutions in ways that haven’t been done in the past. The one issue that I’m sure will pop up though is the specter of unfair competitive advantage. I suppose that there will always be folks that would rather have a hackable computer instead of a few monolithic technology companies.

Train Wreck in Progress!

November 7th, 2009

Every once in a while I get to watch something that is just eerily fascinating. This is one of those times. Human nature, the economy, and the legal system have come together to create a perfect environment for the destruction of a company. I was always amazed at companies that shed their sales people when they fall on hard times. I’ve been saying it for years, when it’s money or security that money always wins. I’m seeing it first hand. I’m watching a company that has eliminated all their full-time security employees to save money and they’re going to pay a heavy price. As they were handing their last security person his walking papers, a nasty piece of malware began to circulate on their network. How do I know? The last security person out the door told me. He had been tracking it for a couple of days and was getting ready to take action when he was told he didn’t work there any more.

He wasn’t the only security person out the door either. I know of at least 2 other security professionals that have been let go because their former employer didn’t see the value in keeping them on.

What amazes me is the notion that if there’s no alarms that they don’t need security! A good security program will keep the noise to a minimum while protecting critical information. A CIO shouldn’t have hear about every tiny alarm or alert.

Therein lays the problem: we do a good job while our PR machine rusts! No noise must mean no threats! We need to do a better job of articulating the value of a well run and maintained security program. Unfortunately, I know of one company that is going to learn that lesson the hard way.