Tag Archives: security

When Security Pros WannaCry

Once again the Internet is set to DEFCON level:OH SHIT due the latest ransomware, WannaCry. I’ll refrain from any further analysis of the malware, since it’s already been discussed ad nauseam by every major security vendor. But I will offer the following thoughts.

WTF?! Why is the industry still so bad at dealing with malware? This attack paralyzed organizations like the NHS and impacted carbon units (you know, those things who pay us) in almost 100 countries. But even as the Internet was melting down, organizations were still sluggish to test and apply this patch after it was released.

“In healthcare and other sectors we tend to be very slow to address these vulnerabilities,” says Lee Kim, the director of privacy and security at the Healthcare Information and Management Systems Society.

According to Brian Krebs, Microsoft released a patch for the vulnerability in March 2017, “…but organizations running older, unsupported versions of Windows (such as Windows XP) were unable to apply the update because Microsoft no longer supplies security patches for those versions of Windows.” Woah Nelly, ORGS ARE STILL RUNNING CRITICAL SYSTEMS ON WINDOWS XP?! That OS was released in 2001 and most people don’t even drive cars that old.

And what about all those NextGen security products that are supposed to address zero days? Where was that super-fantastic, heuristic, machine learning AI when we needed it?

The depressing thing about fighting malware is that the most effective solutions are the same as they were a decade ago:

  1. Make sure you’re running an endpoint security product with updated signatures, formerly referred to as antivirus.  Do these programs negatively impact system performance? Oh yeah. Are they foolproof? Hell no. But like a screen door, they filter out the majority of attacks.
  2. Patch and update your devices like it’s 1999.* If you’re running Windows, install the official patch (MS17-010), which closes the affected SMB Server vulnerability used by the attack. Microsoft even released a patch for those unsupported versions of Windows. 

*That’s another Prince reference, in case you missed it.

doves_cry_malware

Tagged ,

Chicken Little Security

It’s been one of those weeks in information security. The kind that makes me think about raising sheep in New Zealand, because they won’t argue with me about APTs and attribution. In addition to the Java/SMTP/FTP vulnerability that has vendors scrambling, I’ve suffered through trying to explain the following:

While I could probably break each of these down and explain how the sky really isn’t falling, I think Val Smith said it best recently:

Are you able to get an accurate inventory of your network?
Can you rebuild any system, anywhere, in less than a day?
Can you push software and configuration changes, including patches, remotely?
Do you have tested backups?
Do you have enough IT/DevOps to keep your environment stable?
Do you have a tested IR plan?
Do you have proven data sources (logs, netflow, full pcap, endpoint telemetry)?

If you answered no to any of those questions, you probably shouldn’t be too worried about SHA collisions. 

Here endeth the rant.

sha-asif

Tagged , ,

Fear and Loathing in DC

Lately it takes a very compelling request to get Mrs. Y to leave the Sanctum Sanctorum and give a talk, but what better topic is there than digital defense? I love the smell of FUD in the morning, whipping people up into a frenzied paranoia, then watching them rush out of the room to get prepaid cell phones and put duct tape over their web cams.

In all seriousness, no matter which side of the political fence you inhabit, no one can argue that government surveillance is at an all-time high. I can’t even get the Security SOC Puppets together in the same room anymore, because they’re demanding a Faraday cage on their contract rider. So I’m happy to offer my perspective and some guidance to help the general public (i.e. nerd-challenged) protect themselves from snooping and digital attacks.

Special thanks to the the former (recovering) attorney and activist who organized the event.

If you don’t trust Slideshare, you can download the presentation here.

Tagged , , ,

Fixing a Security Program

I’m still unsettled by how many security programs are so fundamentally broken. Even those managed and staffed by people with impressive credentials. But when I talk to some of these individuals, I discover the key issue. Many seem to think the root cause is bad tools. This is like believing the only thing keeping you from writing the Next Great American novel is that you don’t have John Steinbeck’s pen or Dorothy Parker’s typewriter.

In reality, most of the problems found in security programs are caused inferior processes, inadequate policies, non-existent documentation  and insufficient standards. If buying the best tools actually fixed security problems, wouldn’t we already be done? The truth is that too many employed in this field are in love with the mystique of security work. They don’t understand the business side, the drudgery, the grunt work necessary to build a successful program.

For those people, here’s my simple guide.  I’ve broken it down to the following essential tasks:

  1. Find your crap. Everything. Inventory and categorize your organization’s physical and digital assets according to risk. If you don’t have classification standards, then you must create them.
  2. Document your crap. Build run books. Make sure you have diagrams of networks and distributed applications. Create procedure documents such as IR plans. Establish SLOs and KPIs. Create policies and procedures governing the management of your digital assets.
  3. Assess your crap. Examine current state, identify any issues with the deployment or limitations with the product(s). Determine the actual requirements and analyze whether or not the tool actually meets the organization’s needs. This step can be interesting or depressing, depending upon whether or not you’re responsible for the next step.
  4. Fix your crap. Make changes to follow “best practices.” Work with vendors to understand the level-of-effort involved in configuring their products to better meet your needs. The temptation will be to replace the broken tools, but these aren’t $5 screwdrivers. Your organization made a significant investment of time and money and if you want to skip this step by replacing a tool, be prepared to provide facts and figures to back up your recommendation. Only after you’ve done this, can you go to step 6.
  5. Monitor your crap. If someone else knows your crap is down or compromised before you do, then you’ve failed. The goal isn’t to be the Oracle of Delphi or some fully omniscient being, but simply more proactive. And you don’t need to have all the logs. Identify the logs that are critical and relevant and start there: Active Directory, firewalls, VPN, IDS/IPS.
  6. Replace the crap that doesn’t work. But don’t make the same mistakes. Identify requirements, design the solution carefully, build out a test environment. Make sure to involve necessary stakeholders. And don’t waste time arguing about frameworks, just use an organized method and document what you do.

Now you have the foundation of any decent information security program. This process isn’t easy and it’s definitely not very sexy. But it will be more effective for your organization than installing new tools every 12 months.

 

Tagged , , , , , , , ,

Splunk Funk

Recently, I was asked to evaluate an organization’s Splunk deployment. This request flummoxed me, because while I’ve always been a fan of the tool’s capabilities, I’ve never actually designed an implementation or administered it. I love the empowerment of people building their own dashboards and alerts, but this only works when there’s a dedicated Splunk-Whisperer carefully overseeing the deployment and socializing the idea of using it as self-service, cross-functional tool.  As I started my assessment, I entered what can only be called a “dark night of the IT soul” because my findings have led me to question the viability of most enterprise monitoring systems.

The original implementer recently moved on to greener pastures and (typically) left only skeletal documentation. As I started my investigation, I discovered  a painfully confusing distributed deployment built with little to no understanding of  “best practices” for the product. With no data normalization and almost non-existent data input management, the previous admin had created the equivalent of a Splunk Wild West, allowing most data to flow in with little oversight or control. With an obscenely large number of sourcetypes and sources, the situation horrified Splunk support and they told me my only option was to rebuild, a scenario that filled me with nerd-angst.

In the past, I’ve written about the importance of using machine data for infrastructure visibility. It’s critical for security, but also performance monitoring and troubleshooting. Log correlation and analysis is a key component of any healthy infrastructure and without it, you’re like a mariner lost at sea. So imagine my horror when confronted by a heaping pile of garbage data thrown into a very expensive application like Splunk.

Most organizations struggle with a monitoring strategy because it simply isn’t sexy. It’s hard to get business leadership excited about dashboards, pie charts and graphs without contextualizing them in a report. “Yeah baby, let me show you those LOOOOW latency times in our web app.” It’s a hard sell, especially when you see the TCO for on-premise log correlation and monitoring tools. Why not focus on improving a product that could bring in more customer dollars or a new service to make your users happier?  Most shops are so focused on product delivery and firefighting, they simply don’t have cycles left for thinking about proactive service management. So you end up with infrastructure train wrecks, with little to no useful monitoring.

While a part of me still believes in using the best tools to gain intelligence and visibility from an infrastructure, I’m tired of struggling. I’m beginning to think I’d be happy with anything, even a Perl script, that works consistently with a low LOE. I need that data now and no longer have the luxury of waiting until there’s a budget for qualified staff and the right application. Lately, I’m finding it pretty hard to resist the siren song of SaaS log management tools that promise onboarding and insight into machine data within minutes, not hours. Just picture it: no more agents or on-premise systems to manage, just immediate visibility into data.  Most other infrastructure components have moved to the cloud, maybe it’s inevitable for log management and monitoring. Will I miss the flexibility and power of tools like Splunk and ELK? Probably, but I no longer have the luxury of nostalgia.

 

 

Tagged , , , , ,

Danger: Stunt Hacking Ahead

On 4/18, Ars Technica reported on a recent 60 Minutes stunt-hacking episode by some telecom security researchers. During the episode, US representative Ted Lieu had a cell phone intercepted via vulnerabilities in the SS7 network. I’m no voice expert*, but it’s clear that both the 60 Minutes story and the Ars Technica article are pretty muddled attempts to dissect the source of these vulnerabilities. This is probably because trying to understand legacy telephony protocols such as SS7 is only slightly less challenging than reading ancient Sumerian.

Since I was dubious regarding the “findings” from these reports,  I  reached out to my VoIP bestie, @Unregistered436.

Screenshot 2016-04-20 11.33.19

 

While we can argue over how useful media FUD is in getting security issues the attention they deserve, I have other problems with this story:

  • This isn’t new information. Researchers (including the ones appearing in 60 Minutes) have been reporting on problems with SS7 for years. A cursory Google search found the following articles and presentations, including some by the Washington Post.

German Researchers Discover a Flaw That Could Let Anyone Listen to Your Cell Calls 12/18/14

Locating Mobile Phones Using Signalling System #7 1/26/13

For Sale: Systems that Can Secretly Track Where Cellphone Users Go Around the Globe 8/24/14

Toward the HLR, Attacking the SS7 & SIGTRAN Applications H2HC, Sao Paulo, Brazil, December 2009

  • If you’re going to reference critical infrastructure such as the SS7 network, why not discuss how migration efforts with IP convergence in the telco industry relate to this issue and could yield improvements? There are also regulatory concerns which impact the current state of the telecommunications infrastructure as well. Maybe Ted Lieu should start reading all those FCC documents and reports.
  • Legacy protocols don’t get ripped out or fixed overnight (IPv4 anyone?), so the congressman’s call to have someone “fired” is spurious. If security “researchers”  really want things to change, they should contribute to ITU, IEEE and IETF working groups or standards committees and help build better protocols. Or *shudder* take a job with a telecom vendor. We all need to take some ownership to help address these problems.

*If you want to learn more about telecom regulation, you should definitely follow Sherry Lichtenberg. For VoIP and SS7 security, try Patrick McNeil and Philippe Langlois.

Tagged , , , , , ,

The Endpoint Is Dead To Me

Another day, another vulnerability. This month the big non-event was Badlock, following the recent trend of using a splashy name to catch the media’s attention so they could whip the management meat puppets into a paranoid frenzy. Many in the security community seem unperturbed by this latest bug, because let’s face it, nothing can surprise us after the last couple of really grim years.

But then more Java and Adobe Flash bugs were announced, some new iOS attack using Wi-Fi and NTP that can brick a device, followed by an announcement from Apple that they’ve decided to kill QuickTime for Windows instead of fixing a couple of critical flaws. All of this is forcing  me to admit the undeniable fact that trying to secure the endpoint is a waste of time. Even if you’re using a myriad of management tools, patching systems, vulnerability scanners, and DLP agents; you will fail, because you can never stay ahead of the game.

The endpoint must be seen for what it truly is: a limb to be isolated and severed from the healthy body of the enterprise at the first sign of gangrene. It’s a cootie-ridden device that while necessary for our users, must be isolated as much as possible from anything of value. A smelly turd to be flushed without remorse or hesitation. No matter what the user says, it is not valuable and nothing of value to the organization should ever be stored on it.

This doesn’t mean I’m advocating removing all endpoint protection or patching agents. But it’s time to get real and accept the fact that most of this corporate malware is incapable of delivering what the vendors promise. Moreover, most often these applications negatively impact system performance, which infuriates our users. But instead of addressing this issue, IT departments layer on more of this crapware on the endpoint, which only encourages users to find ways to disable it. One more security vulnerability for the organization. A dedicated attacker will figure out a way to bypass most of it anyway, so why do we bother to trust software that is often more harmful to business productivity than the malware we’re trying to block?  We might as well give out “Etch A Sketches” instead of laptops.

google_on_my_etch_a_sketch_by_pikajane-d3846dy

Tagged , , , , , ,

Fear and Loathing in Vulnerability Management

Vulnerability management – the security program that everyone loves to hate, especially those on the receiving end of a bunch of arcane reports. Increasingly, vulnerability management programs seem to be monopolizing more and more of a security team’s time, mostly because of the energy involved with scheduling, validating and interpreting scans. But does this effort actually lead anywhere besides a massive time suck and interdepartmental stalemates? I would argue that if the core of your program is built on scanning, then you’re doing it wrong.

The term vulnerability management is a misnomer, because “management” implies that you’re solving problems. Maybe in the beginning scanning and vulnerability tracking helped organizations, but now it’s just another method used by security leadership to justify their every increasing black-hole budgets. “See? I told you it was bad. Now I need more $$$$ for this super-terrific tool!”

Vulnerability management programs shouldn’t be based on scanning, they should be focused on the hard stuff: policies, standards and procedures with scans used for validation. If you’re stuck in an endless cycle of scanning, patching, more scanning and more patching; you’ve failed.

You should be focused on building processes that bake build standards and vulnerability remediation into a deployment procedure. Work with your Infrastructure team to support a DevOps model that eliminates those “pet” systems. Focus on “cattle” or immutable systems that can and should be continuously replaced when an application or operating system needs to be upgraded. Better yet, use containers. Have a glibc vulnerability? The infrastructure team should be creating new images that can be rolled out across the organization instead of trying to “patch and pray” after finally getting a maintenance window. You should have a resilient enough environment that can tolerate change; an infrastructure that’s self-healing because it’s in a state of continuous deployment.

I recognize that most organizations aren’t there, but THIS should be your goal, not scanning and patching. Because it’s a treadmill to nowhere. Or maybe you’re happy doing the same thing over and over again with no difference in the result. If so, let me find you a very large hamster wheel.

hamster_meme

 

Tagged , , , , , ,

Introducing: Security SOC Puppets

Gert and Bernie

Please join Gert, Bernie and friends in their wild adventures through cyberspace! In episode one, our woolen friends explore the frustrating topic of email encryption.

Tagged , , , ,

Security Threat Levels with a Side of FUD

Today the SANS Internet Storm Center raised it’s Infocon Threat Level to “yellow” due to the recently announced backdoor in Juniper devices. I wouldn’t have even known this if someone hadn’t pointed it out to me and then I felt like I was in an episode of Star Trek. I kept waiting for the ship’s computer to make an announcement so I could strap myself into my chair.

While the level names are different, the colors seem to mirror the old Homeland Security color-coded advisory system, which was eliminated in 2011 due to questions over it’s usefulness.

2000px-Hsas-chart_with_header.svg

According to a story on CNN.com:

“The old color coded system taught Americans to be scared, not prepared,” said ranking member Rep. Bennie Thompson, D-Mississippi. “Each and every time the threat level was raised, very rarely did the public know the reason, how to proceed, or for how long to be on alert. I have raised concerns for years about the effectiveness of the system and have cited the need for improvements and transparency. Many in Congress felt the system was being used as a political scare tactic — raising and lowering the threat levels when it best suited the Bush administration.”

I have a similar experience with SANS’ Infocon and the reactions from management.

Pointy-haired Fearless Leader: OMG, the SANS Infocon is at YELLOW!!! The end of the Internet is nigh!

Much Put-Upon Security Architect: Please calm down and take a Xanax. It’s just a color.

I’d like to propose a simpler and more useful set of threat levels with recommended actions. Let’s call it the Postmodern Security Threat Action Matrix:

Level Description Action
Tin Foil Hat Normal levels of healthy paranoia You can still check your email and watch Netflix. But remember they’re always watching….
Adult Diaper It’s damn scary out there. Trust no one. Remember to update your Tor browser. Have your “go bag” ready.
Fetal Position Holy underwear Batman, it’s the end. Destroy all electronic devices and move into a bomb shelter. The Zombie Apocalypse is imminent.
Tagged , , , , ,
%d bloggers like this: