Tag Archives: security

A Cautionary Security Tale

Early this morning a Facebook acquaintance, henceforth known as “S,” reached out to me with an interesting problem. Some time ago, she bought a laptop from a liquidation auction at Living Social. When she finally got around to booting it up, she discovered something concerning. What follows is our conversation:

S: Hey there! have a tech question for you….I bought a laptop from an auction at Living Social a couple of months ago. Said laptop was supposed to have been wiped clean, but it wasn’t (requires the former users password). Tried calling/emailing Living social, but they’ve been completely non responsive. How can I reboot it?

Mrs. Y: that’s quite frightening, that someone’s personal data is on a laptop that was resold. I can try reaching out to contacts at Living Social, but probably won’t get you much. Was it supposed to come with an operating system already installed?

S: When it boots up it MS7 Enterprise. It’s not supposed to come with an operating system.

Mrs. Y: Yikes. Okay, I would just reinstall, unless you want me to break into it and figure out which organization or individual was silly enough to give an unwiped laptop over to an auction. If it’s MS 7 enterprise, I’m betting that it was an organization and it might have confidential data on it. FYI this is every security professional’s nightmare

S: it was Living Social. They were liquidating from their 9th street office. That’s why I tried reaching out to them. Thought it made sense to let them know and I could bring it back to them so they could wipe it.

Mrs. Y: (Where I finally realize that the laptop formerly BELONGED to Living Social, not simply being resold by them.) holy crap!



that’s friggin’ hysterical

Mrs. Y: You are so honest. Most would have already broken into it. I can reach out to contacts, but you can probably wipe. I mean, that’s probably the safest thing for you to do. Honestly, they probably won’t have time to deal with it or care since they’re downsizing. They won’t have the staff to deal with it. Worst part is that it doesn’t seem to be encrypted.

S: If you want to break into it, I’m fine with that! I feel I did my due diligence in alerting them.

Mrs. Y: (Yielding to my better nature) I reached out to them via Twitter. BTW, is there anything that identifies the system as previously having belonged to Living Social? An asset tag or branding when the OS boots up? Feel free to send me screenshots.

Mrs. Y: #FACEPALM. I’m horrified.
S: I’m so annoyed. But I also wondered how many other units weren’t wiped.
Mrs. Y: You’re trying to do the right thing by letting them know.

 Moral of the story: Make sure your organization has a disposal policy and procedure. Here endeth the lesson.
Tagged ,

OPM Hack: What We Can Learn

I frequently write for actual publications and my latest article is an analysis of the OPM breach. What I hope makes mine different is that I tried to avoid the schadenfreude so common in the industry and focus on what we could all learn and correct in our own organizations.

From TechTarget SearchNetworking

When Office of Personnel Management (OPM) Director Katherine Archuleta gave her cringe-worthy testimony before Congress earlier this summer, it felt like a nightmare from the IT collective unconscious. A series of embarrassing appearances revealed she didn’t seem to know essential details of the OPM hack or understand the problems that allowed OPM to be compromised twice in one year. Her resignation seemed a forgone conclusion and a relief for the .GOV crowd.

So what went wrong?

It would be a mistake to categorize the compromise as simply a failure in OPM’s security strategy, because the agency’s entire information technology program was a management catastrophe — a guidebook in what not to do. In watching testimony and reading reports from the Office of the Inspector General (OIG), it isn’t only the security failures that stand out, but clueless leadership that flunked at basic strategy and risk management. This kind of negligence is all too familiar to those of us with any tenure in IT. Reading those OIG reports feels like déjà vu, because they could be about almost any enterprise.

Full article continued here.

Tagged , , ,

PCI Purgatory*

*Updated: Now with Extra Snark!

Let me clarify, I’m not a QSA, ISA or any other type of SA**. But as the senior architect for a security team, I’m usually expected to have the last word on technical implementations. Like many, I’ve been stuck in PCI purgatory since the release of the 3.0 standard. New requirements to interpret, countless discussions with the QSA and the acquirer, arguments with the rest of the organization who barely understand payments and think they get to have an opinion: it makes me want to shred all my own credit cards. In addition to the scoping changes with ecommerce, the Service Provider definition was modified.

Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).
Okay, I admit it, I didn’t pay much attention to this. It didn’t really seem that different. But the devil is in the nuanced PCI details. We recently engaged a contractor who performs third-party security for my organization. He was new to PCI DSS and we wanted to modify our TSP questionnaire to capture PCI DSS status if the partner was capturing payment card data for us and interacting with our payment processor on our behalf, using our merchant ID. He actually READ the new standard, pointing out that these entities were now considered service providers and to my horror, I discovered he was correct. I also realized that EVERYONE seems to be freaking out over this, most getting it completely wrong.

If there was even one iota of doubt left in my mind, this section from the PCI DSS Information Supplement: Third Party Security Assurance resolved it:

Examples of ThirdParty Service Providers

Below are examples of types of services and providers with which an entity may work:

  • Organizations involved in the storage, processing, and/or transmission of cardholder data (CHD). Third-party service providers in this category may include:
    • Call centers
    •  E-commerce payment providers
    •  Organizations that process payments on behalf of the entity, such as a partner or reseller
    • Fraud verification services, credit reporting services, collection agencies
    • Third-party processors
    • Entities offering processing-gateway services
  • Organizations involved in securing cardholder data. TPSPs in this category may include:
    • Companies providing secure destruction of electronic and physical media
    • Secure storage facilities for electronic and physical media
    • Companies that transform cardholder data with tokenization or encryption
    • E-commerce or mobile-application third parties that provide software as a service
    • Key-management providers such as key-injection services or encryption-support organizations (ESO)
  •  Organizations involved in the protection of the cardholder data environment (CDE). TPSPs in this category may include:
    • Infrastructure service providers
    • Managed firewall/router providers
    • Secure data-center hosting providers
    • Monitoring services for critical security alerts such as intrusion-detection systems (IDS), anti- virus, change-detection, compliance monitoring, audit-log monitoring, etc.
  • Organizations that may have incidental access to CHD or the CDE. Incidental access is access that may happen as a consequence of the activity or job. TPSPs in this category may include:
    • Providers of managed IT delivery channels and services
    • Companies providing software development, such as web applications
    • Providers of maintenance services

So stop arguing with reality (and me). Oh and for the record, I don’t care what you, your mom, your dry cleaner, or another merchant thinks about PCI. I love those people who spend 30 minutes going through the standard and think they understand it because they’ve read the words. As most of us know who’ve worked with PCI for any amount of time, it’s a bit like pornography. Everyone has a different definition. As far as security and compliance teams are concerned, the only opinions that matter come from the acquirer, the QSA and the organization’s ISA. Moreover, a security team for an organization usually has thousands of hours of combined experienced in PCI DSS. A non-practitioner offering us “suggestions” is the equivalent of someone offering Misty Copeland advice about her grand jetes after taking one ballet class.

**Qualified Security Assessor, Internal Security Assessor

Tagged , , ,

Security for Luddites

Dear Family and Friends,

I know many of  you are still trying to figure out what I do for a living and that you don’t really understand my Twitter feed. Some of you are confused why I give you a hard time about your poor passwords or the fact that you forgot to use BCC in an email. Let’s just say I have your best interests at heart when I take the time to alert you about a serious security vulnerability. If I take the time to let you know about some new nastiness making the Internet a dangerous place, please update. #Include <long-winded technical explanation about SOP violation, RCE, etc…>.  I care about you and know that you don’t have the time or energy to keep up with the machinations of the black hat community. Just know that it’s bad and I’ll feel terrible if your Gmail account gets hacked. Mostly, because telling friends their accounts have been hacked feels like telling them someone ran over their dog.

Your Favorite Nerd,

Mrs. Y.

Tagged , ,

Being the Security Asshole

Yes, I have become a security asshole. The one who says “no” to a technology. But I say it because of risk, and not just security risk.  And I’m angry, because my “no” is a last resort after many struggles with developer, engineering and operations teams in organizations that struggle to get the basics right.

I try to work with teams to build a design. I bring my own architecture documents and diagrams, which include Powerpoint presentations with talking points. I create strategy road maps explaining my vision for the security architecture in an organization. I detail our team’s progress and explain how we want to align with the rest of enterprise strategy and architecture. I stress that our team exists to support the business.

What do I get in return? Diagrams so crude, they could be drawn in crayon or made with Legos. They usually don’t even have IP addresses or port numbers. I have to argue with sysadmins about whether Telnet is still an acceptable protocol in 2015. I’m subjected to rehashed Kool-Aid about how some product is going to rescue the organization even though I found significant vulnerabilities during the assessment, which the vendor doesn’t want to fix.

And if this means that you hate me, fine. I’ll be the asshole. I’ll embrace it. But at least I can have a clear conscience, because I’ve done my best to safeguard the organization that’s paying me.

Tagged , , , , ,

Cognitive Dissonance and Incident Response

“In psychology, cognitive dissonance is the mental stress or discomfort experienced by an individual who holds two or more contradictory beliefs, ideas, or values at the same time, or is confronted by new information that conflicts with existing beliefs, ideas, or values.”

Festinger, L. (1957). A Theory of Cognitive Dissonance. California: Stanford University Press.

For your consideration, what follows is the hypothetical discussion between a Pointy Haired Fearless Leader and a Security Analyst regarding the possibility of an organization’s large, web application having been breached. The Frankenapp in question was creatively duct-taped together around the same time that dinosaurs roamed the earth. All characters appearing in this work are fictitious. Any resemblance to real persons living or dead, is because truth is often much funnier than fiction.

SA: There’s a possibility our Super Amazing Custom Web Application has been breached.

PHFL: (Breathes into paper bag as starts to hyperventilate. In between breaths) How did this happen?!

SA: Same way it always does. A user was phished.

PHFL: But why didn’t our Extraordinarily Powerful Security Tools that cost $$$$$ stop this?!

SA: Because they don’t always work. Especially when they don’t have all the data necessary to identify malicious activity.

PHFL: But we paid $$$$$ because the vendor said it would stop APTs!

SA: This isn’t an APT.

PHFL: But we have Super Powerful Web Application Firewalls!

SA: They’re still in learning mode, because the web developers won’t work with us to identify false positives. And a WAF won’t detect phished credentials. We need multi-factor authentication to prevent this.

PHFL: But MFA annoys the users. What about the network firewalls?!

SA: Our firewalls wouldn’t have caught this and our web filtering system hasn’t worked for months.

PHFL: Do we know what accounts were compromised?

SA: We don’t have enough data. We don’t really have many application logs and the ones we do have aren’t being sent to the  SOC to be correlated.

PHFL: Why wasn’t I told about this tragic and desperately horrible situation?!

SA: I’ve been telling you every week since I took the job. I even hired someone to sky-write it twice. I’m also working on an off-Broadway musical called, We’re About to be Pwned Because Our Visibility Stinks and Our Security Tools Are Broken.

PHFL: Well, this is clearly your fault.

Dilbert On Incident Response

Tagged , , , , , ,

Security Karma

The Hacking Team debacle continues to make life miserable for defenders everywhere. Any vestige of organizational good will I  may have built up over the last year, is gone after issuing five emergency patch requests over ten days. I’m exhausted and still wondering how many more 0-days are lurking around the corner.

The compromise was epic, with hackers releasing approximately 400GB of data, including thousands of internal emails and memos which were posted on Wikileaks. Reuters reported that all this mayhem was caused by six disgruntled former employees who also released Hacking Team source code.  Frankly, I don’t have much sympathy for David Vincenzetti and his circle of douchery that includes government clients using Hacking Team’s brand of malware to spy on dissidents. While following the story, a Confucian proverb came to mind. “When you ride a tiger, it’s hard to get off.”

And so it has been for The Hacking Team, now bitten by that proverbial tiger and broken, a casualty of their own hubris. Whether they can recover from this disaster is questionable. Their arrogance only surpassed by that other sad sack of the security industry, HBGary, taken down by Anonymous.

There is a story of a soldier who went to see a famous Buddhist Monk, Ajahn Chah, to ask why he had been shot on the battlefield. Why had he been chosen to suffer, was it something he had done in a past life? Ajahn Chah answered that it was the karma of a soldier to be wounded. The real meaning of karma isn’t punishment, it’s simple cause and effect. With the Hacking Team it’s a case of security karma: they chose to enter the arena of offensive security and use the tools of attackers for questionable purposes. By doing so, they increased the odds that they would themselves become an object of retaliation.

Tagged , , ,

Security’s Bad Boys

This week’s latest stunt hacking episode seemed to cement the security community’s reputation as the industry bad boy. The Wired car hacking story demonstrated an absence of the responsible disclosure most security researchers strive to follow. While the story indicated that Miller and Valasek have been working with Chrysler for nine months and that they’re leaving out a key element of the published exploit, there’s still going to be enough left to cause some mayhem when released at Black Hat USA next month. Moreover, the story’s writer and innocent bystanders were often in harm’s way during the demonstration on a major highway in St. Louis.

The annual Black Hat conference in Vegas is an adult version of “look what I can do” for the security set, perfectly placed in the city’s carnival atmosphere. A grand spectacle where every breaker competes to get Daddy’s attention by taking apart the toaster, or car in this case. The media loves this stuff and floods outlets with paranoia-inducing stories the few weeks before and during the conference.  What’s so disturbing about these events isn’t the frailty of our technology-enabled stuff aka “Internet of Things,” but the need for a subset of people to focus on its faults. The typical rationale from many of these researchers for their theatrical, hype-infested releases during Black Hat and other security conferences, is that they can’t get any attention from manufacturers when going the path of responsible disclosure. I would argue that this behavior is more about ego than concern for the safety of consumers, because there are plenty of principled researchers, quiet heroes who slog along filing bugs with vendors, unknown and overlooked by the general public.

Most idiots can blow up a cathedral with enough C-4. But it takes a Bernini or Michelangelo with hundreds of talented, dedicated artisans, to design and build one. People who will never be remembered by tourists standing in the middle St. Peter’s, glorying in the majesty of such an achievement.

St. Peter's

Tagged , , , , , , ,

Dear Flash, It’s Over

Dear Adobe Flash,

It’s probably insensitive of me to do this in a blog post, but I can’t trust myself to be alone with you anymore. The relationship started out great. Those cute kitten and puppy videos would get me through the most stressful days, when I just needed to turn off my brain off after a day of navigating the network poopfest at work. I wish we could go back and start over again, but after three patches in a week, I’m done. This just isn’t working for me anymore. Okay, I know we could still have some fun times, but I simply don’t feel safe with you anymore. So I’m going to have to end it. And to be clear, it’s not me, it’s you.

P.S. I’d just like to point out the irony of a recent Wired article, “Flash.Must.Die.” It has a Flash popup.

Screenshot 2015-07-16 09.31.52

Tagged , , , ,

The MSSP Is the New SIEM

In the last year, I’ve come to a realization about incident management. In most cases, buying a SIEM is a waste of money for the enterprise. The software and licensing cost isn’t trivial, some of them utilizing what I like to call the “heroin dealer” or consumption licensing model. The first taste is free or inexpensive, but once you’re hooked, prepare to hand over your checkbook, because the costs often spiral out of control as you add more devices. Additionally, for most small to medium organizations, the complicated configuration often requires a consulting company to assist with the initial implementation and at least one full-time employee to manage and maintain. Even then, you won’t really have 24×7 monitoring and alerting, because most can’t afford a large enough staff to work in shifts, which means you’re dependent upon email or text alerts. That’s not very useful if your employees actually have lives outside of work. Most often, what you’ll see is an imperfectly implemented SIEM that becomes a noise machine delivering little to no value.

The SIEM’s dirty secret is that it’s a money pit. Once you add up the software and licensing cost, the professional services you spend to get it deployed and regularly upgraded, the hardware, the annual support cost, and staffing, you’re looking at a sizable investment. Now you should ask yourself, are you really reducing risk with a SIEM or just hitting some checkbox on a compliance list?

Alternatively, let’s look at the managed security service provider (MSSP). For a yearly cost, this outsourced SOC will ingest and correlate your logs, set up alerts, monitor and/or manage devices 24×7, 365 days a year. An MSSP’s level-1 and level-2 staff significantly reduce the amount of repetitive work and noise your in-house security team must deal with, making it less likely that critical incidents are missed. The downside is that the service is often mediocre, leaving one with the sneaking suspicion that these companies are happy to employ any warm body to answer the phone and put eyeballs on a screen. This means that someone has to manage the relationship, ensuring that service level agreements are met.

While there are challenges with outsourcing, the MSSP is a great lesson in the economy of scale. The MSSP is more efficient in delivering service because it performs the same functions for many customers.  While not cutting-edge or innovative, the service is often good enough to allow a security team to focus on the incidents that matter without having to sift through the noise themselves. The caveat? While useful in the short-term, security teams should still focus on building proactive controls with automation and anomaly detection for improved response. After all, the real goal is to make less garbage, not more sanitation workers.

Tagged , , , ,
%d bloggers like this: