If you've been in the IT industry long enough, you'll start seeing the same concepts "reinvented" every few years or so.

The current panacea is so-called Bring Your Own Device--the idea that an end user can use their own technology devices in a corporate setting while having some level of access to corporate data. While we went through this with laptops and personal computers over the years, now the devices we are bring our own of? Mobile phones/tablets.

Another acronym I've heard recently describes the state of IT, again, as long as I've been in it--Corporate Owned, Personally Enabled. Here, the idea is that a corporate-owned asset is used for an employee's personal needs. This has been the case with corporate-owned PCs forever without any formal policy for the last couple of decades. Now we're starting to see this with mobile devices, either with or without the use of third party tools.

The reality is that, regardless of whether companies adopt BYOD, COPE, something else, or neither, the reality is, employees are going to use personal devices to do work. And, likewise, use corporate devices for "personal use." This has always been the case and will always be the case, regardless of any formal policies to the contrary.

From a security point of view, this creates some rather obvious issues. On corporate-owned devices, some sort of "device management" or "Endpoint Security" offering is installed, which users tolerate to varying degrees. (I happen to like Check Point's Endpoint Security offering, but I will admit, I'm biased.) BYOD won't work because users are often asked to submit "device management" or an "Endpoint Security" installation in order to use their own device on the corporate network.

But ask yourself: what is it that you're really trying to protect on that endpoint? Prevent malicious software? You have a properly segmented network, right? You have the technology to detect any malicious traffic from that segment, right? Good. That should take care of it.

But what if the software doesn't "phone home" while on the corporate network (or generate malicious traffic), but collects data and then sends it out over the mobile operator's network? Modern mobile operating systems have these things called sandboxes that prevent one app from reading data from another in the first place. Obviously, if you're jailbroken or rooted, all bets are off.

And malicious apps, while not unheard of, are nearly non-existent in the official App Stores for iOS or Android. Same with potential privilege escalation-type attacks in iOS and Android. Not impossible but a lot harder to pull off, given that Android and (moreso) iOS are pretty secure out-of-the-box.

Really there's only one thing to worry about on these devices: the corporate data. This data needs to be protected. Which is generally pretty easy to do assuming only a trusted application is able to access the data, the regular OS protections are in place (i.e. device isn't rooted or jailbroken). And, of course, the data has to come on and off the device in a secure manner (e.g. either with strong encryption or using a physical access mechanism).

Once you have the magic, trusted app (or suite of apps) to access, work with, and secure the small amounts of corporate data the device can work with, congratulations! You've now eliminated the headache of managing potentially unknown devices in the hands of users who will do everything they can to thwart your security controls anyway. If users want to work with corporate data, they can use the "trusted" apps to do it, which should have appropriate hooks back to corporate to validate whether you are able to even use the data and, if you or your device goes rogue, wipe the data from your device without wiping the entire device (which has personal data on it).

While I believe there are great solutions along these lines (yet), this is the only kind of solution I believe makes any sense in the long term. People will be able to bring their own devices and access business data while infosec will rest easy knowing business data is still  accessed and stored safely.

It's a BYOD solution everyone can COPE with.

The implementation details will vary depending on the attack target and the request type, but the basic concept of a denial of service is to overwhelm a target with a seemingly legitimate series of requests so that real requests are ignored and not processed. If the attack is launched from multiple points on the network, it is referred to as a distributed denial of service attack (a.k.a. DDoS).

I remember when I first started hearing about denial of service issues more than 10 years ago. I even played with a few tools to generate them on my own--in my own network, of course. Back then, defenses for this sort of thing simply didn't exist. Aiming a tool at a helpless server protected by an even more helpless firewall was a great way to wreak havoc.

In general, there are two ways to create a Denial of Service condition:

  • Cause the relevant service to crash. This is actually pretty difficult to do in a simple fashion given the resiliency of most public-facing services, though for lesser-used services, it can happen.
  • Resource exhaustion, where some resource needed to provide the service (bandwidth, buffers, etc) is depleted in a way that causes the service to not respond to legitimate requests.

Over the years, every part of the service stack has gotten more resilient against the most basic form of these attacks. For example, a simple SYN flood won't take down most web servers these days as web servers are smart enough not to allocate resources to a connection until the three-way handshake completes. That said, if you can get a few million of your closest friends to run Low Orbit Ion Cannon at a server, or visit a particular webpage, you can still take down a target.

To give you a real-world example of this, I'll talk briefly about a recent denial of service someone brought to Check Point's attention via a Pastebin posting. The attack, ironically, was not all that different from the first SYN floods I played with more than a decade ago.

According to the report on Pastebin, the security researcher was able to essentially cause a Check Point Security Gateway to stop processing packets by sending ~120k packets per second. That's easy to generate inside a VMware environment, or even on an isolated network segment. Over an Internet link? Depends on the size of the pipe.

Regardless of how realistic that particular incoming packet rate may be in a given environment, what happens when the gateway sees that much traffic? In many cases, it simply runs out of memory, causing traffic to be dropped. It also runs out of processor capacity to forward said traffic.

Since the only way to truly stop a denial of service attack is to disconnect from the Internet, your best hope is that the various components are optimally configured to operate in potential denial of service conditions. Check Point's official response to this issue mentions four specific configuration changes that can be made to their security gateways:

  1. Implementing the IPS protection "SYN Attack" feature in SYN cookie mode, which will reduce the memory footprint caused by these bogus connection attempts.
  2. A hotfix for SPLAT/GAiA systems that, along other things, optimizes how the SYN+ACK packets that come back from the server are processed (IPSO does not require this).
  3. Where applicable, use multiqueue to increase the number of processors that can handle traffic on a given interface.
  4. Increasing the receive buffers on the interface.
These settings have proven to be effective at mitigating a potentially large SYN flood. That said, there's only so much you can do. Your Internet link is still a potential bottleneck. Your Security Gateways, even optimally configured, can only process so much traffic.
Unfortunately, there is no silver-bullet solution to this problem other than bigger and better servers--or security gateways. This means that denial of service is something we're going to have to battle with for a long time.

Recently, I was approached by a few people inside Check Point about doing a security-focused blog. I could have easily done this on phoneboy.com, though despite its history as being the definitive place to go for information related to Check Point FireWall-1 back in ye olden days, I decided to leave the current site as-is.

My goal here on phoneboy.net is to share my own insights about things going on in the computer and network security space. I've done that in the past on phoneboy.com, but my goal is to do it here with a singular focus. I will also leverage some of the brightest minds at Check Point to explain things that, quite frankly, I don't understand, and share that insight with you.

Just to be clear: I work for Check Point, and I will surely share Check Point-related things here, but this blog will be my own thoughts.

Testing Readability with a Bunch of Text

Portland in shoreditch Vice, labore typewriter pariatur hoodie fap sartorial Austin. Pinterest literally occupy Schlitz forage. Odio ad blue bottle vinyl, 90’s narwhal commodo bitters pour-over nostrud. Ugh est hashtag in, fingerstache adipisicing laboris esse Pinterest shabby chic Portland. Shoreditch bicycle rights anim, flexitarian laboris put a bird on it vinyl cupidatat narwhal. Hashtag artisan skateboard, flannel Bushwick nesciunt salvia aute fixie do plaid post-ironic dolor McSweeney’s. Cliche pour-over chambray nulla four loko skateboard sapiente hashtag.

Vero laborum commodo occupy. Semiotics voluptate mumblecore pug. Cosby sweater ullamco quinoa ennui assumenda, sapiente occupy delectus lo-fi. Ea fashion axe Marfa cillum aliquip. Retro Bushwick keytar cliche. Before they sold out sustainable gastropub Marfa readymade, ethical Williamsburg skateboard brunch qui consectetur gentrify semiotics. Mustache cillum irony, fingerstache magna pour-over keffiyeh tousled selfies.

Cupidatat 90’s lo-fi authentic try-hard

In pug Portland incididunt mlkshk put a bird on it vinyl quinoa. Terry Richardson shabby chic +1, scenester Tonx excepteur tempor fugiat voluptate fingerstache aliquip nisi next level. Farm-to-table hashtag Truffaut, Odd Future ex meggings gentrify single-origin coffee try-hard 90’s.

  • Sartorial hoodie
  • Labore viral forage
  • Tote bag selvage
  • DIY exercitation et id ugh tumblr church-key

Incididunt umami sriracha, ethical fugiat VHS ex assumenda yr irure direct trade. Marfa Truffaut bicycle rights, kitsch placeat Etsy kogi asymmetrical. Beard locavore flexitarian, kitsch photo booth hoodie plaid ethical readymade leggings yr.

Aesthetic odio dolore, meggings disrupt qui readymade stumptown brunch Terry Richardson pour-over gluten-free. Banksy american apparel in selfies, biodiesel flexitarian organic meh wolf quinoa gentrify banjo kogi. Readymade tofu ex, scenester dolor umami fingerstache occaecat fashion axe Carles jean shorts minim. Keffiyeh fashion axe nisi Godard mlkshk dolore. Lomo you probably haven’t heard of them eu non, Odd Future Truffaut pug keytar meggings McSweeney’s Pinterest cred. Etsy literally aute esse, eu bicycle rights qui meggings fanny pack. Gentrify leggings pug flannel duis.

Forage occaecat cardigan qui

Fashion axe hella gastropub lo-fi kogi 90’s aliquip +1 veniam delectus tousled. Cred sriracha locavore gastropub kale chips, iPhone mollit sartorial. Anim dolore 8-bit, pork belly dolor photo booth aute flannel small batch. Dolor disrupt ennui, tattooed whatever salvia Banksy sartorial roof party selfies raw denim sint meh pour-over. Ennui eu cardigan sint, gentrify iPhone cornhole.

Whatever velit occaecat quis deserunt gastropub, leggings elit tousled roof party 3 wolf moon kogi pug blue bottle ea. Fashion axe shabby chic Austin quinoa pickled laborum bitters next level, disrupt deep v accusamus non fingerstache.

Tote bag asymmetrical elit sunt. Occaecat authentic Marfa, hella McSweeney’s next level irure veniam master cleanse. Sed hoodie letterpress artisan wolf leggings, 3 wolf moon commodo ullamco. Anim occupy ea labore Terry Richardson. Tofu ex master cleanse in whatever pitchfork banh mi, occupy fugiat fanny pack Austin authentic. Magna fugiat 3 wolf moon, labore McSweeney’s sustainable vero consectetur. Gluten-free disrupt enim, aesthetic fugiat jean shorts trust fund keffiyeh magna try-hard.

Hoodie Duis

Actually salvia consectetur, hoodie duis lomo YOLO sunt sriracha. Aute pop-up brunch farm-to-table odio, salvia irure occaecat. Sriracha small batch literally skateboard. Echo Park nihil hoodie, aliquip forage artisan laboris. Trust fund reprehenderit nulla locavore. Stumptown raw denim kitsch, keffiyeh nulla twee dreamcatcher fanny pack ullamco 90’s pop-up est culpa farm-to-table. Selfies 8-bit do pug odio.

Thundercats Ho!

Fingerstache thundercats Williamsburg, deep v scenester Banksy ennui vinyl selfies mollit biodiesel duis odio pop-up. Banksy 3 wolf moon try-hard, sapiente enim stumptown deep v ad letterpress. Squid beard brunch, exercitation raw denim yr sint direct trade. Raw denim narwhal id, flannel DIY McSweeney’s seitan. Letterpress artisan bespoke accusamus, meggings laboris consequat Truffaut qui in seitan. Sustainable cornhole Schlitz, twee Cosby sweater banh mi deep v forage letterpress flannel whatever keffiyeh. Sartorial cred irure, semiotics ethical sed blue bottle nihil letterpress.

Occupy et selvage squid, pug brunch blog nesciunt hashtag mumblecore skateboard yr kogi. Ugh small batch swag four loko. Fap post-ironic qui tote bag farm-to-table american apparel scenester keffiyeh vero, swag non pour-over gentrify authentic pitchfork. Schlitz scenester lo-fi voluptate, tote bag irony bicycle rights pariatur vero Vice freegan wayfarers exercitation nisi shoreditch. Chambray tofu vero sed. Street art swag literally leggings, Cosby sweater mixtape PBR lomo Banksy non in pitchfork ennui McSweeney’s selfies. Odd Future Banksy non authentic.

Aliquip enim artisan dolor post-ironic. Pug tote bag Marfa, deserunt pour-over Portland wolf eu odio intelligentsia american apparel ugh ea. Sunt viral et, 3 wolf moon gastropub pug id. Id fashion axe est typewriter, mlkshk Portland art party aute brunch. Sint pork belly Cosby sweater, deep v mumblecore kitsch american apparel. Try-hard direct trade tumblr sint skateboard. Adipisicing bitters excepteur biodiesel, pickled gastropub aute veniam.

Like many things in Computer/Network Security, I've learned many things as a result of my job. Not because I necessarily wanted to learn them :)

PCI Compliance is one of those things I've encountered a handful of times during my tour of duty at Check Point. I don't even pretend to play an expert on PCI on the Internet, which stands for Payment Card Industry (i.e. companies that process credit cards). The goal of the various PCI standards is pretty simple: ensure the credit card data of customers remains protected as it is captured, stored, and transmitted on the various systems that process it.

What does this have to do with Parking Lots? Many parking lots, especially in big cities like Seattle, are self-service. You pre-pay with a credit card, get a ticket from the machine, and put it in your windshield. A minimum wage lackey (hereafter referred to as parking lackey) periodically checks the lot to make sure everyone who has parked there has paid, issuing parking tickets for those who have not.

I parked in one such lot recently in downtown Seattle. They issued me a receipt like this (except both halves were attached and the personally identifiable data was not blacked out):

What was on this stub was the type of card I have and the last four digits of said card. I was asked to place this on my windshield. In plain sight. For anyone to walk by and collect.

To comply with the posted signs, I did leave the ticket in plain view on my dash, but only the right (smaller) half, which had the least personally identifying information on it. Unfortunately, the parking lackey didn't think I had complied with the rules and issued me a parking violation, which I immediately contested.

PCI-DSS Requirement 7 is to restrict access to cardholder data by business need to know, where "access rights are granted to only the least amount of data and privileges needed to perform a job." Does the parking lackey need to know what credit card I used to pay my parking fee with? Does he need the last four digits of my credit card? And even if he does (and I'm not sure on what planet that information would be required by a parking lackey), why do I also have to expose this information to the general public?

I realize that, in the grand scheme of things, this is not a huge data exposure. The number of people that likely saw the relatively small amount of data is pretty close to zero. That said, at least how I read the PCI-DSS 2.0 requirements, this is a clear-cut violation of the guidelines.

Clearly, I need to keep a sharpie in my car so I can comply with these parking lot rules yet maintain the confidentiality of my personal data.

Am I right? Is this a violation of PCI guidelines? Do other parking systems do stuff like this?