When a Breach Hits Home
by Michael Starks
Bloggers and writers often lament the challenge of finding new material. When we do write about a topic, it is often a second-hand story, perhaps commenting on the big news of the day. This month is different, thanks to Gexa Energy, an electricity provider based in Houston, Texas.
Last month, my wife received a letter from Gexa Energy informing her that a data breach may have involved her non-public personal information. I guess they weren’t entirely sure. The letter describes how their monitoring systems alerted them to the intrusion on April 30, 2008, the date of the incident. The breach was contained and there is no evidence of any improper use of her information (had her information ever actually been involved). They even caught the person responsible and are prosecuting them, Gexa says.
Did you notice the timeframe between the discovery of the breach and the notification? I didn’t, until I read about it again in a news story. Almost a year passed before they let anyone know. But don’t worry, law enforcement told them not to tell anyone.
The letter went on to list the types of information that might have been accessed, which included the usual suspects: drivers license number, social security number, date of birth and so on. The next underlined sentence emphasized that no credit card numbers or bank account numbers were compromised.
Gexa was even helpful enough to point my wife to some sources for credit monitoring and reports, although these are already free resources. Finally, they created the ironically titled http://www.gexaenergy.com/dataprotection site to help everyone feel better about the whole thing. The letter closed with the usual statement of how they take things real serious-like and how they deeply regret her concern. No one signed the letter.
How a company responds after a breach is a strong indicator of their commitment to protecting your information. In this case, Gexa failed miserably. They:
1. Failed to accept personal responsibility for the breach by not having an executive sign the letter.
2. Failed to conclusively state what information had been accessed, and when.
3. Made no offer to pay for personal credit monitoring.
4. Used emphasis in the letter to minimize their culpability and responsibility.
5. Made the inexcusable and legally questionable decision to wait almost a full year before notifying affected people of the breach.
Breaches happen. In today’s world, that’s a fact. With this breach, Gexa’s response only serves to remind us that honesty is the best policy. Passing the buck and failing to take personal responsibility will only alienate customers who might otherwise have been willing to forgive you.
Daydreams of Failure
by Michael Starks
Fellow Catalyst Blogger Adam Dodge recently wrote about failure. In his blog entry, he muses about how failure can lead to increasingly better results. Fail better, he offers, rather than try for perfection.
What is information security if not the study of how systems fail? While consumers of information systems expect them to succeed, a seasoned security professional is looking for the obvious and arcane ways in which an apparently healthy system can fail.
When computer systems are patched, policies enforced and viruses quarantined, we presume to have succeeded. Yet when unsubstantiated rumors affect the company stock price, we relegate that failure to someone else. But the end result is the same: a system has failed and the company has been adversely affected.
Failures of computer systems are well understood in our profession, but failures of information systems are rarely as appreciated. Information takes many forms and the risk to information is not always at the end of an electrical socket. If a water line were to break, would that be an information systems failure? Certainly it is a failure, but who considers water line failures a risk to information? However, if the water line were to break and the office flooded, would the filing cabinets be affected? Are they full of original, historical documents?
What if the marketing team orders t-shirts with the names of all of the employees who succeeded at delivering a project on-time? This is great for morale. Is it equally as morale-boosting to a social engineer?
The evolution of information security will certainly involve a re-examination of how we define systems and how they fail. Freed from the bridles of IT, the future information security practitioner will look around the environment and start asking questions based on what he sees. He will see interactions between seemingly ordinary objects as creating ad-hoc systems, with information freely flowing among them. He will daydream and begin asking questions like, “What happens to the business if it gets 1000 bad reviews on Amazon.com? How does the elimination of the training budget affect our ability to retain veteran employees?” Or, to put things in a more recent context, “What would happen if the bank reduced our business line of credit?”
What systems do you see around you? How can they fail? How would a failure lead to harm for the company? Kick back your feet and stare at the sky for awhile. You might be surprised.
An Open Letter to CEOs
by Michael Starks
Dear Chief Executive Officer,
I want to help.
When you hired me as a security professional, I had certain expectations. I expected that you would come to me for guidance when evaluating new technologies. I expected that you would solicit my feedback when engaging in risky ventures. I expected that, as a professional, my security expertise would be valued.
I want to help you pass audits. In order to do that, you need to understand that passing the audit is not the actual goal. To pass audits, we need to have a security program that is perpetually healthy–one that creates and builds a security culture. It needs to be healthy enough where passing audits is a natural consequence of how we handle information.
I want to help you stay safe from attack. In order to do that, we need to not only perform risk analysis, but also act on the results. We need to take these results and turn them into action plans. We will sometimes need a budget to make these things happen.
I want to help you avoid fines, bad publicity and more regulations. In order to do that, we will need to actually enforce the security policy we already have, and which you signed off on. Yes, that means consequences for those who willingly violate.
I just wanted you to know that when you put systems into production and say, “we’ll do the security stuff later,” I can’t help you in the best way possible. When you start audit activities two months before the audit, then try to negotiate away the exceptions, I can’t help you in the best way possible. And when you don’t approve a critical patch on a production system because it might break something, I can’t help you in the best way possible.
I want to help you sell your product. In order to do that, the business has to stay safe enough to meet your goals. Let’s work together to find creative ways to protect the business.
Yours in security,
The Security Professional
It’s Time to Pay the Piper
By Michael Starks
Why do companies keep losing our personal information? That, of course, is the billion dollar question. Theories abound, and while we all theorize about the causes, data is still being compromised at an alarming rate.
Allow me to add to the theorizing, fully aware that this is going to sound a bit unconventional. What follows is not so much a concrete theory and solution, but an offering for creative thought. Here’s my take on one of the main reasons breaches happen, followed by a crazy idea about what we can do about it.
Breaches happen because companies are only looking out for number one.
Sorry, you’re not number one. They are. You are but a meaningless number in a pool of data. They have no attachment to you as an individual and only view your risk as a function of their own. If your risk doesn’t factor into their own, it is casually disregarded. In the event of a breach of your personal information, they will act in their own self-interest. They are unlikely to compensate you for your time, stress, loss of work or anything else directly related to that breach. You get the short end of the stick.
That’s the bad news. The good news is that it doesn’t have to be this way. We can change things.
Payment is Past Due: The Action Plan
When our personal risk becomes a real economic factor in the risk of someone holding our information, the balance of the scales will have tipped. Since it is unlikely that companies will find incentives to factor in personal risk, they need to be persuaded through personal privacy and data security legislation.
It might work something like this. From the multitude of breach statistics collected, we develop a profile of the harm done to a typical person after a breach of a certain type. One would expect, for example, that a lost social security number be more personally harmful than a lost credit card number. That breach profile is then used to assign relative security requirements to companies that wish to deal with that aspect of your data self. The more personal, static and valuable the information, the more stringent the requirement.
To validate that the data is sufficiently protected, the company will be required to undergo independent penetration tests. Audits, while sometimes helpful, are insufficient in that they primarily measure compliance and not the ability to withstand attack. We need to know how safe the data really is.
Here’s where the rubber meets the road. For every failed test, the company will be required to pay premiums to those whose information they are not adequately protecting, proportionate to the amount of risk the test reveals. In traditional insurance models, the insurance company holds risk. You pay them to assume that risk. With this model, the company is putting you in a similar position of risk. Doesn’t it follow that you should be similarly compensated?
In this paradigm, the company doesn’t get to wait until the information is actually breached. They lose the ability to roll the dice, and hope everything is going to be OK, while you remain at risk They face actual consequences, not just for breaches, but for creating circumstances predisposed to a breach. And with ongoing consequences for doing a poor job of protecting information, it then becomes in their best economic interest to get and remain secure.
By now you are undoubtedly thinking thoughts such as, “this won’t work because..” or “but what about.” Good. The idea wasn’t so much to offer a single solution to a complex problem; rather, it was to spark realization that we can change the rules of the game. No longer do we have to be victims. What are the problems with my proposal? How can it be re-worked? What ideas do you have to win back your identity? Throw me a comment or let’s chat in the forums.
Security Program Success: 9 tips for ‘09
By Michael Starks
2008 was a year like no other. Then again, it was a year where not much had changed. We learned about the Kaminsky DNS vulnerability through an unprecedented, coordinated advisory. Systems not patched with MS08-067 became compromised with the Conficker worm. PCI-compliant companies fell prey to attack. We even accused governments of sponsoring attacks against out national infrastructure. Yet, despite the sensationalism, despite the potential for devastation on a large scale, our responses were largely, well, non-sensational.
As a student of human behavior, I have noticed patterns in the way we protect information. We tend to follow the same rote actions and fall into the same habits. Take, for example, the Kaminsky bug. It was big news. The DNS infrastructure was at stake. The inevitable exploit was released. Some companies patched and others decided to wait it out. And then… nothing. You hardly hear a word about it anymore. Did everyone finally patch their systems? Of course not.
I observed three categories of response to this vulnerability, with these responses generally following other risks.
- Those who did a true risk analysis and decided, based on that risk analysis, what to do.
- Those who were moved emotionally by the audacity of the possible impact, patched.
- Those who felt as if they are unlikely to be attacked, or had higher priorities, waited it out.
People in the first category realized that emotional responses can’t always be trusted and sometimes only an objective process can bring things into perspective. People in the second category were sufficiently scared into action, regardless of the true potential for compromise. People in the third category made emotional decisions based on an immediate perceived lack of risk. And if that risk didn’t materialize quickly, it was forgotten. If these categories are generally true, then two out of three people made an emotional response to a perceived risk. In other words, most of us wing it.
Although emotional responses to risk can cloud judgment, understanding human behavior is an important part of your security program I’m not going to tell you how to respond to risk; rather, let’s focus on those things security programs usually lack: an understanding of how humans behave. How we can use that knowledge to get things done? Here’s 9 tips for ‘09:
1. Make it easier.
Make it as easy as possibly, but no more. Make it easy for you, for management, and for end users. Easy things have appeal. Complex things evoke pushback and negative reaction. One of the first questions you should be asking in designing a security solution or response is: how can I make this easy? The last question should be: how can I make this easier the next time?
2. Be approachable.
I’ll be the first to admit that this isn’t easy for us technical types. We generally like to control our environment. We’re used to working with machines, not people. But security programs are run by and affect, people. So it makes sense to be a nice guy or gal. When you’re approachable, people want to talk to you about the issues they face. When they do that, you have an opportunity to help them by finding a secure solution to their problem.
3. Go beyond the corporate mandate.
People generally don’t ask to be secure. They just expect it as a condition of their work. But that doesn’t mean they have no security concerns. It is my experience that many want to be involved. They want to do the right thing and be rewarded for it. But corporate security is full of boring policies and procedures that no one wants to read. When you give them something they can use personally, such as ways to prevent identity theft, they’re often willing to take some medicine with the sugar.
4. Toot your own horn.
When a security countermeasure has protected the business, let people know. Security is hard enough to justify, so make sure others know about successes. When it comes time to ask for money, having a list of successes will help justify the expenditure. This also takes a bit of the edge off the not-so-successful endeavors.
5. Consider the environment.
How likely is your security measure to be accepted? Does it make sense to install a man trap in a company with no AV? Are your admins savvy enough to implement and maintain a network access control solution? While risk should be the main motivator for these decisions, it’s important to consider the practical considerations. Shoot high, but not so high that you lose sight of the ball.
6. Go for the small wins, first.
Nothing builds on success like success. If you have a big project coming up, make sure there is some easy stuff up front. It will motivate and encourage people, and take away some of the trepidation. Being successful makes people feel good. When people feel good it’s easier to work with them and they do better work.
7. Reward good behavior.
Pop quiz: name three sanctions in your security program, then name three rewards. What? You write people up, fire them and threaten them with arrest, but you can’t hand out some movie tickets once in awhile? Make people feel good and they’re more likely to repeat that behavior.
8. Learn from the past.
None of us are perfect. Our security programs have successes and failures, but with the failures come an opportunity to figure out what went wrong. Use these valuable opportunities to fine-tune your program. Use them to become more approachable, toot your own horn and reward good behavior–you get the idea.
9. Consider the big picture.
Take a step back every once in awhile to think about the program, as a whole. Is it accomplishing the objectives you set for it? Are you caught in the trap of fixing problems the industry says you must fix? Are you spending time mitigating the MD5 collision problem when you don’t have patch management working? By looking at the big picture, you can get a better feel as to where your limited resources are most effectively spent.
Security programs are all about people. We often say that it’s about people, process and technology, but it’s the people who must implement process and technology. Understand people and you will understand how to protect information.
When Burning Buildings Become Blasé
by Michael Starks
Imagine if a building on every street started on fire every day. They are small fires, which cause relatively little damage, and are usually quickly extinguished by the sprinkler system. Every once in awhile, the entire house burns down because the sprinkler system hasn’t been updated in over a year. Now imagine that people have come to believe that this is normal and expected, that as long as you keep your sprinkler system updated, you should be OK. And if the sprinkler system does its job, the fires aren’t a problem.
While analogies are never perfect, this is the basic situation we have today with viruses and anti-virus software. Billions of dollars are spent in defending against viruses, with software ranging from simple desktop scanners to multi-tired, enterprise class anti-virus defense ecosystems. When they catch viruses and other forms of malware, we judge them to be successful. We run reports with nice graphs to show management, and as long as the viruses are being caught, we feel our information is safe.
While few dispute that anti-virus software is a necessity in a modern computing environment (particularly, one which contains Microsoft Windows), fewer still frame anti-virus in the proper context. How many look at the number of viruses caught, juxtapose them with the effectiveness of the software in catching viruses, and make a plan to reduce the number of viruses detected? In other words, how many ensure the anti-virus software is working as intended, then work to reduce the infection rate?
Viruses and other malware are not simple problems to solve, but there are solutions to reducing the number of infections that do not depend on the use of anti-virus software. Among them:
-Reducing the rights a user has to run and install software. Do your users run with Administrator rights by default? Why? If they’re not changing network settings, installing software and looking at logs on a regular basis, most people don’t need these rights as a part of their normal job.
-Educating users about safe computing. When a virus is detected, do you interview the user in an attempt to determine how the infection occurred? Viruses, at least for now, are not spontaneous phenomena. Something happens for that infection to take root. Usually, unsafe computing behavior is involved.
-Educating users about appropriate use. Are your users installing personal software or games (see #1), connecting to untrusted networks or surfing to personal web sites? To what extent are you willing to allow for these activities versus the cost of increased virus rates?
-Examining the choke points for data entering the network. While the perimeter is becoming increasingly porous, looking at data flow is critical in determining how infections occur. Do most occur from drive-by downloads, or are they due to e-mail attachments? By looking at data flow, protections can be put into place to reduce the chance of viruses entering the network.
Notice that all of the points mentioned involve process, education and analysis. None of them involve spending more money on more defense technology. While that may at times be the natural outcome of the process, it should not be the first reaction.
Anti-virus software isn’t perfect; in fact, the ability for anti-virus software to detect modern malicious code has been declining in recent years. While still needed, we need to look our perception of its role in protecting information. Is it our first and only line of defense or is it an alarm that something else has failed? By shifting our thinking to the root causes of infections, and by focusing on solutions to those problems, we can reframe anti-virus software as primarily IDS, rather than IPS. We can set goals for increasing the effectiveness of preventing malicious code, while simultaneously reducing the number of detections found.
Virus infections are an anomaly that we have been trained to accept as normal. By shifting our thinking towards anti-virus as a rarely activated sprinkler system, we’ll go a lot further towards keeping our information safe.
Michael is an Information Security Professional specializing in host-based security, IDS, log analysis and compliance. He believes in applying basic security principles to an ever-changing threat landscape, and is currently exploring the various ways in which human behavior affect the success of security programs. He is a founding member of the Rochester, NY chapter of ISSA and has served for both ISSA and OWASP. He currently holds the CISSP, GSNA and A+ certifications. In his spare time, Michael enjoys spending time with his wife and daughter, and listening to early twentieth-century blues.
Engage with Michael
-
Journey Into the Breach
