I started running when I was 10. I started because my mom was talking a college PE class, so I used to tag along and no one seemed to care. We ran laps three nights a week. I loved doing it and by twelve I was lapping the field in the 20 minutes allotted. I lived 6 miles from my junior high and high school so I used to run home. I could have walked, ridden a bike, or taken rides from friends who offered, but I chose to run. I was on the track team and I ran cross country – the latter had us running 10 miles a day before I ran home. And until I discovered weight lifting, and added some 45 lbs of upper body weight, I was pretty fast.
I used to run 6 days week, every week. Run one evening, next day mid-afternoon, then morning; and repeat the cycle, taking the 7th day off. That way I ran with less than 24 hours rest four days days, but it still felt like I got two days off. And I would play all sorts of mental games with myself to keep getting better, and to keep it interesting. Coming off a hill I would see how long I could hold the faster speed on the flat. Running uphill backwards. Going two miles doing that cross-over side step they teach you in martial arts. When I hit a plateau I would take a day and run wind sprints up the steepest local hill I could find. The sandy one. As fast as I could run up, then trot back down, repeating until my legs were too rubbery to feel. Or maybe run speed intervals, trying to get myself in and out of oxygen deprivation several times during the workout. If I was really dragging I would allow myself to go slower, but run with very heavy ‘cross-training’ shoes. That was the worst. I have no idea why, I just wanted to run, and I wanted to push myself.
I used to train with guys who were way faster that me, which was another great way to motivate. We would put obscene amounts of weight on the leg press machine and see how many reps we could do, knee cartilage be damned, to get stronger. We used to jump picnic tables, lengthwise, just to gain explosion. One friend like to heckle campus security and mall cops just to get them to chase us because it was fun, but also because being pursued by a guy with a club is highly motivating. But I must admit I did it mainly because there are few things quite as funny as the “oomph-ugghh” sound rent-a-guards make when they hit the fence you just casually hopped over. For many years after college, while I never really trained to run races or compete at any level, I continued to push myself as much as I could. I liked the way I felt after a run, and I liked the fact that I can eat whatever I want … as long as I get a good run in.
Over the last couple years, due to a combination of age and the freakish Arizona summers, all that stopped. Now the battle is just getting out of the house: I play mental games just to get myself out the door to run in 112 degrees. I have one speed, which I affectionately call “granny gear”. I call it that because I go exactly the same speed up hill as I do on the flat: slow. Guys rolling baby strollers pass me. And in some form of karmic revenge I can just picture myself as the mall cop, getting toasted and slamming into chain link fence because I lack the explosion and leg strength to hop much more than the curb. But I still love it as it clears my head and I still feel great afterwards … gasping for air and blotchy red skin notwithstanding. Or at least that is what I am telling myself as I am lacing up my shoes, drinking a whole bunch of water, and looking at the thermometer that reads 112. Sigh Time to go …
On to the Summary:
Webcasts, Podcasts, Outside Writing, and Conferences
- Adrian’s Dark Reading post on What You Should Know About Tokenization.
- Rich’s The Five Things You Need to Know About Social Networking Security, on the Websense blog.
- Chris’s Beware Bluetooth Keyboards with iOS Devices, starring Mike – belated, as we forgot to include it last time.
Favorite Securosis Posts
- Rich: NSO Quant: Firewall Management Process Map (UPDATED).
- Mike Rothman: What Do We Learn at Black Hat/DefCon?
- Adrian Lane: Incite 8/4/2010: Letters for Everyone.
Other Securosis Posts
- Tokenization: Use Cases, Part 1.
- GSM Cell Phones to Be Intercepted in Defcon Demonstration.
- Tokenization: Series Index.
- Tokenization: Token Servers, Part 3, Deployment Models.
- Tokenization: Token Servers, Part 2 (Architecture, Integration, and Management).
- Death, Irrelevance, and a Pig Roast.
Favorite Outside Posts
- Mike Rothman: Website Vulnerability Assessments: Good, Fast or Cheap – Pick Two. Great post from Jeremiah on the reality of trade-offs.
- Adrian Lane: How Microsoft’s Team Approach Improves Security. What is it they say about two drunks holding each other up?
- David Mortman: Taking Back the DNS. Vixie & ISC plan to build reputation APIs directly into BIND.
- Rich Mogull: 2010 Data Breach Investigations Report Released. VZ Business continues to raise the bar for data and breach analysis. 2010 version adds data from the US Secret Service. Cool stuff.
- Chris Pepper: DefCon Ninja Badges Let Hackers Do Battle. I hope Rich is having fun at DefCon – this sounds pretty good, at least.
Project Quant Posts
- NSO Quant: Manage Firewall Policy Review Sub-Processes.
- NSO Quant: Firewall Management Process Map (UPDATED).
- NSO Quant: Monitor Process Revisited.
- NSO Quant: Monitoring Health Maintenance Subprocesses.
- NSO Quant: Validate and Escalate Sub-Processes.
- NSO Quant: Analyze Sub-Process.
- NSO Quant: Collect and Store SubProcesses.
Research Reports and Presentations
- White Paper: Endpoint Security Fundamentals.
- Understanding and Selecting a Database Encryption or Tokenization Solution.
- Low Hanging Fruit: Quick Wins with Data Loss Prevention.
- Report: Database Assessment.
Top News and Posts
- Patch for Critical Windows Flaw Available.
- Infoworld SIEM Review.
- Marketers Spying on Internet Users.
- Siemens Scada System Hit By Worm.
- How to Do Application Logging Right by Anton Chuvakin and Gunnar Peterson.
- Jeremiah Grossman’s preso on Hacking Auto Complete.
- More BlackBerry Bashing…But What’s the Real Story?
Blog Comment of the Week
Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Mark Bower of Voltage, in response to and older FireStarter: An Encrypted Value Is Not a Token!
Regarding your statement: “Key here is to remember, PCI DSS is allowing systems that substitute credit card data with tokens to be removed from the audit based upon the premise that PAN data is not available”
I’d be interested if you could point to the specific part of PCI DSS today that states that Tokens remove systems from the validation requirements. There’s a lot of work going on in this area but nowhere does this get stated in PCI DSS to be clear.
Thus, merely claiming one is “using Tokenization” may or may not reduce scope and may or may not increase security: it has to be done right: only a QSA can make that decision when looking at the specifics of an implementation.
A lot of claims are made about Tokenization security, and many are not based on science. I would also point out that getting Tokenization right is a lot more involved than merely substituting data and managing a Data Vault. Many of the types of attacks on cryptosystems still apply in slightly different forms to Tokenization systems especially if such systems do not pay very good attention to the token generation process, exactly what you tokenize in the first place, and most importantly how you manage credentials and access to BOTH the tokenizing system and detokenizing system and any images of it that are distributed.
The suggestion that Tokenization is “simple” is also a somewhat misleading statement: if you have to manage, sync, distribute and contain a growing database of tokens, keys and other sensitive materials (credentials), monitor it etc, then this starts to become a significant surface to risk manage – especially the entry and exit points and their data paths. Also, how do you manage a re-tokenize event if your token systems somehow have been compromised so the tokens themselves can now be manipulated, injected and abused? Assuring that the tokenizing engine has not been tampered with or the sources of entropy used to generated tokens are within specification are all considerations. One cannot underestimate the ingenuity of todays sophisticated attackers.
An open access tokenizer for example may permit a successful table based attack on a poorly implemented system given knowledge of cardholder data patterns. A badly design hashing token approach which does not pay attention to security may lead to simple compromise without even attacking the token database. VISA’s guidance is refreshing to see more rigor being necessary. Perhaps these types of attacks are what VISA indicated in their statement:
“Where properly implemented, tokenization may help simplify a merchant’s payment card environment,” said Eduardo Perez, Head of Global Payment System Security, Visa Inc. “However, we know from working with the industry and from forensics investigations, that there are some common implementation pitfalls that have contributed to data compromises. For example, entities have failed to monitor for malfunctions, anomalies and suspicious activity, allowing an intruder to manipulate the tokenization system undetected. As more merchants look at tokenization solutions, these best practices will provide guidance on how to implement those solutions effectively and highlight areas for particular vigilance,”