Research

I realize this will shock many of you, but I hated beer in high school and the first couple years of college. I know, I know, this destroys your image of me, but it’s the truth. I blame it on orange soda. My parents weren’t big soda drinkers, so I wasn’t really exposed to it. The first time I tried an orange soda at a birthday party in elementary school, the carbonation freaked me out and that was the end. My anti-carbonation stance carried over when we started on beer in high school (don’t tell the cops). Plus, beer back then sucked. I was still a young male and would drink beer when nothing else was around, but I tended towards kamikazes. Until the night I got so drunk that when my friends dropped me off at home I freaked out over someone stealing my car. You know, the one I drove to the bar earlier that night and (wisely) left there. The hangover lasted three days – so much for the immunity of youth. But then I discovered Buff Gold. In 1990 the Walnut Brewery, the first brew pub in Boulder, opened up. Shortly afterwards I was hired as a 19 year old 140 lb (wet) bouncer. It was a mellow crowd. I couldn’t drink there as an underage employee, but a couple other bars owned by the same guy carried the beer. Buffalo Gold was the first ale I ever tried, and started me down a path of refined malty (and responsible) consumption. As a side note, Frank Day, the owner, later opened the first Rock Bottom brewery in Denver (same franchise, different name). He also started the Old Chicago’s chain. Rock Bottom is all over the place, and merged with Gordon Beirsch a few years ago, which also owns Big River Brewery, the only brew pub at Disney World (on the Boardwalk). I keep showing my Walnut Brewery nametag at Disney, but they still make me pay for my beers. When they let me in the door. Anyhoo… after Buff Gold came Fat Tire, which migrated down from Fort Collins an hour north of Boulder. Then all sorts of craft beers exploded, which explains why the American Homebrewers Association offices were around the corner from my old Boulder condo. Turns out I didn’t hate beer, I just hated bad beer. After I moved to Phoenix a Yard House opened up near us and my (now) wife and I started spending most Friday happy hours there. That’s when I met The Bastard. Arrogant Bastard, if you are being formal, and it is about as serious a beer as you can find. After that anything short of an IPA seemed almost tasteless, and I became obsessed with California hops. I also loved the naming and marketing used by the Stone Brewing company. Beers like Ruination and Sublimely Self Righteous. Tag lines like, “You’re Not Worthy” and “you probably won’t like this beer”. When my wife was pregnant with our first child she deigned to take the Stone Brewery tour when we were out in San Diego, despite being unable to drink. That’s when I realized the marketing genius of their aggressive, no-nonsense approach. After… a few pints… I emailed Adrian and informed him I had our new corporate branding. “No B.S. Research”, “If you want to feel good about yourself, call your mom. If you want a security program, call us”, and the rest of our site and attitude. It has been five years since that trip, and our distinct divergence from traditional professionalism. And you know what? People like honesty. And the ones who don’t aren’t the sorts we want to work with anyway. It’s a nice filter that drives the kinds of clients and engagements that make this such an awesome job, and save us from endless piles of lapdogging and paperwork. And it all started with a beer. Like anything else worth a damn. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted on DBaaS. Dave Lewis in The Atlantic: This Little House in Wyoming Didn’t Just Get Flooded With Web Traffic From China. Favorite Securosis Posts Adrian Lane: The Catalyst. Someone sent me the book this week. Care to guess who? Rich: The SIXTH Annual Disaster Recovery Breakfast (with 100% less boycott). Yes, it’s a repost, but RSVP anyway. Other Securosis Posts Mindfulness Works. Firestarter: Target and Antivirus. Eliminate Surprises with Security Assurance and Testing [New Paper]. Favorite Outside Posts Adrian Lane: Metadata for beginners 😉. My favorite of the week was not a post, but a tweet. It only takes a couple fat-fingered cell calls from a ‘suspect’ to make you part of their social circle. Chris Pepper: More security is always better, right? Domain registrar auto-enrolls customers into $1,850 security service. Er. Dave Lewis: The death of Windows XP. Rich: Increased Cyber Security Can Save Global Economy Trillions. Funny numbers, but once again we see security hitting the mainstream. Research Reports and Presentations Eliminate Surprises with Security Assurance and Testing. What CISOs Need to Know about Cloud Computing. Defending Against Application Denial of Service Attacks. Executive Guide to Pragmatic Network Security Management. Security Awareness Training Evolution. Firewall Management Essentials. A Practical Example of Software Defined Security. Continuous Security Monitoring. API Gateways: Where Security Enables Innovation. Identity and Access Management for Cloud Services. Top News and Posts Chinese Internet Traffic Redirected to Small Wyoming House. Huh. Notes from Shmoocon 2014. Office.com Defaced by Syrian Electronic Army. RootCloak Hides Root Access From Specific Applications. Chrome hack lets websites keep listening after you close the tab. “70,000 healthcare.gov records hacked” claim turns out to be Google results. Oops; press fail. Again. Blog Comment of the Week This week’s best comment goes to DS, in response to A Very Telling Antivirus Metric. “We stop 0 day* attacks” *in this sense 0 indicates the number of attacks we successfully stop. Always gotta read the fine print. Share:

In this week’s Firestarter Rich, Mike, and Adrian discuss the latest in the Target relevations and whether over-reliance on antivirus is to blame once again. We aren’t out to blame the victim. We also pick our top prevention strategies for this sort of attack. Ain’t hindsight great? Share:

From Brian Krebs’ awesome reporting on the Target breach (emphasis added): The source close to the Target investigation said that at the time this POS malware was installed in Target’s environment (sometime prior to Nov. 27, 2013), none of the 40-plus commercial antivirus tools used to scan malware at virustotal.com flagged the POS malware (or any related hacking tools that were used in the intrusion) as malicious. “They were customized to avoid detection and for use in specific environments,” the source said. That source and one other involved in the investigation who also asked not to be named said the POS malware appears to be nearly identical to a piece of code sold on cybercrime forums called BlackPOS, a relatively crude but effective crimeware product. BlackPOS is a specialized piece of malware designed to be installed on POS devices and record all data from credit and debit cards swiped through the infected system. I swear I’ve been briefed by a large percentage of those vendors on how their products stop 0-day attacks. Let me go find my notes… Share:

I am currently polishing off the first draft of my Data Security for iOS 7 paper, and reached one fascinating conclusion during the research which I want to push out early. Apple’ approach is implementing is very different from the way we normally view BYOD. Apple’s focus is on providing a consistent, non-degraded user experience while still allowing enterprise control. Apple enforces this by taking an active role in mediating mobile device management between the user and the enterprise, treating both as equals. We haven’t really seen this before – even when companies like Blackberry handle aspects of security and MDM, they don’t simultaneously treat the device as something the user owns. Enough blather – here you go… Apple has a very clear vision of the role of iOS devices in the enterprise. There is BYOD, and there are enterprise-owned devices, with nearly completely different models for each. The owner of the device defines the security and management model. In Apple’s BYOD model users own their devices, enterprises own enterprise data and apps on devices, and the user experience never suffers. No dual personas. No virtual machines. A seamless experience, with data and apps intermingled but sandboxed. The model is far from perfect today, with one major gap, but iOS 7 is the clearest expression of this direction yet, and only the foolish would expect Apple to change any time soon. Enterprise-owned devices support absolute control by IT, down to the new-device provisioning experience. Organizations can degrade features as much as they want and need, but the devices will, as much as allowed, still provide the complete iOS experience. In the first case users allow the enterprise space on their device, while the enterprise allows users access to enterprise resources; in the second model the enterprise owns everything. The split is so clear that it is actually difficult for the enterprise to implement supervised mode on an employee-owned device. We will explain the specifics as we go along, but here are a few examples to highlight the different models. On employee owned devices: The enterprise sends a configuration profile that the user can choose to accept or decline. If the user accepts it, certain minimal security can be required, such as passcode settings. The user gains access to their corporate email, but cannot move messages to other email accounts without permission. The enterprise can install managed apps, which can be set to only allow data to flow between them and managed accounts (email). These may be enterprise apps or enterprise licenses for other commercial apps. If the enterprise pays for it, they own it. The user otherwise controls all their personal accounts, apps, and information on the device. All this is done without exposing any user data (like the user’s iTunes Store account) to the enterprise. If the user opts out of enterprise control (which they can do whenever they want) they lose access to all enterprise features, accounts, and apps. The enterprise can also erase their ‘footprint’ remotely whenever they want. The device is still tied to the user’s iCloud account, including Activation Lock to prevent anyone, even the enterprise, from taking the device and using it without permission. On enterprise owned devices: The enterprise controls the entire provisioning process, from before the box is even opened. When the user first opens the box and starts their assigned device, the entire experience is managed by the enterprise, down to which setup screens display. The enterprise controls all apps, settings, and features of the device, down to disabling the camera and restricting network settings. The device can never be associated with a user’s iCloud account for Activation Lock; the enterprise owns it. This model is quite different from the way security and management were handled on iOS 6, and runs deeper than most people realize. While there are gaps, especially in the BYOD controls, it is safe to assume these will slowly be cleaned up over time following Apple’s usual normal improvement process. Share:

Last week I wrote up my near epic fail on Amazon Web Services where I ‘let’ someone launch a bunch of Litecoin mining instances in my account. Since then I received some questions on my forensics process, so I figure this is a good time to write up the process in more detail. Specifically, how to take a snapshot and use it for forensic analysis. I won’t cover all the steps at the AWS account layer – this post focuses on what you should do for a specific instance, not your entire management plane. Metadata The first step, which I skipped, is to collect all the metadata associated with the instance. There is an easy way, a hard way (walk through the web UI and take notes manually), and the way I’m building into my nifty tool for all this that I will release at RSA (or sooner, if you know where to look). The best way is to use the AWS command line tools for your operating system. Then run the command aws ec2 describe-instances –instance-ids i-5203422c (inserting your instance ID). Note that you need to follow the instructions linked above to properly configure the tool and your credentials. I suggest piping the output to a file (e.g., aws ec2 describe-instances –instance-ids i-5203422c > forensic-metadata.log) for later examination. You should also get the console output, which is stored by AWS for a short period on boot/reboot/termination. aws ec2 get-console-output –instance-id i-5203422c. This might include a bit more information if the attacker mucked with logs inside the instance, but won’t be useful for a hacked instance because it is only a boot log. This is a good reason to use a tool that collects instance logs outside AWS. That is the basics of the metadata for an instance. Those two pieces collect the most important bits. The best option would be CloudTrail logs, but that is fodder for a future post. Instance Forensics Now on to the instance itself. While you might log into it and poke around, I focused on classical storage forensics. There are four steps: Take a snapshot of all storage volumes. Launch an instance to examine the volumes. Attach the volumes. Perform your investigation. If you want to test any of this, feel free to use the snapshot of the hacked instance that was running in my account (well, one of 10 instances). The snapshot ID you will need is snap-ccd3e9c6. Snapshot the storage volumes I will show all this using the web interface, but you can also manage all of it using the command line or API (which is how I now do it, but that code wasn’t ready when I had my incident). There is a slightly shorter way to do this in the web UI by going straight to volumes, but that way is easier to botch, so I will show the long way and you can figure out the shorter alternative yourself. Click Instances in your EC2 management console, then check the instance to examine. Look at the details on the bottom, click the Block Devices, then each entry. Pull the Volume ID for every attached volume. Switch to Volumes and then snapshot each volume you identified in the steps above. Label each snapshot so you remember it. I suggest date and time, “Forensics”, and perhaps the instance ID. You can also add a name to your instance, then skip direct to Volumes and search for volumes attached to it. Remember, once you take a snapshot, it is read-only – you can create as many copies as you like to work on without destroying the original. When you create a volume from an instance it doesn’t overwrite the snapshot, it gets another copy injected into storage. Snapshots don’t capture volatile memory, so if you need RAM you need to either play with the instance itself or create a new image from that instance and launch it – perhaps the memory will provide more clues. That is a different process for another day. Launch a forensics instance Launch the operating system of your choice, in the same region as your snapshot. Load it with whatever tools you want. I did just a basic analysis by poking around. Attach the storage volumes Go to Snapshots in the management console. Click the one you want, right-click, and then “Create Volume from Snapshot”. Make sure you choose the same Availability Zone as your forensics instance. Seriously, make sure you choose the same Availability Zone as your instance. People always mess this up. (By ‘people’, I of course mean ‘I’). Go back to Volumes. Select the new volume when it is ready, and right click/attach. Select your forensics instance. (Mine is stopped in the screenshot – ignore that). Set a mount point you will remember. Perform your investigation Create a mount point for the new storage volumes, which are effectively external hard drives. For example, sudo mkdir /forensics. Mount the new drive, e.g., sudo mount /dev/xvdf1 /forensics. Amazon may change the device mapping when you attach the drive (technically your operating system does that, not AWS, and you get a warning when you attach). Remember, use sudo bash (or the appropriate equivalent for your OS) if you want to peek into a user account in the attached volume. And that’s it. Remember you can mess with the volume all you want, then attach a new one from the snapshot again for another pristine copy. If you need a legal trail my process probably isn’t rigorous enough, but there should be enough here that you can easily adapt. Again, try it with my snapshot if you want some practice on something with interesting data inside. And after RSA check back for a tool which automates nearly all of this. Share:

Okay, we have content in this thing. We promise. But we can’t stop staring at our new title video sequence. I mean, just look at it! This week Rich, Mike, and Adrian discuss Target, Snapchat, RSA, and why no one can get crisis communications correct. Sorry we hit technical difficulties with the live Q&A Friday, but we think we have the kinks worked out (I’d blame Mike if I were inclined to point fingers). Our plan is to record Friday again – keep an eye on our Google+ page for the details. Share:

Over the past few years I have spent a lot of time traveling the world, talking and teaching about cloud security. To back that up I have probably spent more time researching the technologies than any other topic since I moved from being a developer and consultant into the analyst role. Something seemed different at such a fundamental level that I was driven to put my hands on a keyboard and see what it looked and felt like. To be honest, even after spending a couple years at this, I still feel I am barely scratching the surface. But along the way I have learned a heck of a lot. I realized that many of my initial assumptions were wrong, and the cloud required a different lens to tease out the security implications. This paper is the culmination of that work. It attempts to break down the security implications of cloud computing, both positive and negative, and change how we approach the problem. In my travels I have found that security professionals are incredibly receptive to the differences between cloud and traditional infrastructure, but they simply don’t have the time to spend 3-4 years researching and playing with cloud platforms and services. I hope this work helps people think about cloud computing differently, providing practical examples of how to leverage and secure it today. I would like to thank CloudPassage for licensing the paper. This is something I have wanted to write for a long time, but it was hard to find a security company ready to take the plunge. Their financial support enables us to release this work for free. As always, the content was developed completely independently using our Totally Transparent Research process – this time it was actually developed on GitHub to facilitate public response. I would also like to thank the Cloud Security Alliance for reviewing and co-branding and co-hosting the paper. There are two versions. The Executive Summary is 2 pages of highlights from the main report. The Full Version includes an executive summary (formatted differently), as well as the full report. As always, if you have any feedback please leave it here or on the report’s permanent home page. Executive Summary: What CISOs Need to Know About Cloud Computing (PDF) Full Report: What CISOs Need to Know About Cloud Computing Share:

Rich here. A funny thing happened this week. As I wrote on Tuesday, someone hacked my Amazon Web Services account when I accidentally left my keys in code I pushed up to GitHub. The first line of my code was, This is a bit embarrassing to write. I take my role as a public figure in security pretty seriously. I am thankful every day that I get to do what I do (okay, maybe not the day I was in Kiev in December trying to find a menu I could understand). As an introvert it’s weird to be out there writing and speaking in public on security every day and have people actually read and listen. And to get paid for it. It is entirely too easy to let this go to one’s head, and I’m pretty sure any of you reading this can start counting off some of the names. In my mind I need to keep earning it every day. That means actually knowing what I’m talking about, taking security seriously, and setting an example. I expect to be hacked in the course of what I do, but I strive to avoid dumb mistakes. You know, practice what I preach. Well, I made a series of mistakes – I suppose I am human (or at least humanoid) after all. And I got popped. I always assume something like that will get out, so I might as well break the news myself, and spill the gory details so maybe someone can avoid screwing up like I did. I expected some criticism, but the exact opposite happened. The overwhelming support from the community was astounding. Nobody called me an idiot, and people recognized that I’m just a dude, trying my best, and making mistakes. Contrast this to the recent communications from Target, Snapchat, or any other company that gets breached or screws up. They try their best to cover things up, release as little information as possible, and hope people forget. It never works. Anyone with a modicum of crisis communications training knows that silence and obfuscation sow distrust and uncertainty. This isn’t rocket science. Coming clean was scary and initially painful, but if I expect people to trust me, I need to be open about those sorts of things. In the end, I was riding high all day on the incredible support from the community. From my community. The real lesson? I am totally going to screw some other things up on purpose and talk about it now. I mean, it has to work again next time, right? On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted in DBaaS article. Rich quoted in Dark Reading on speakers leaving the RSA conference. Rich quoted in Computerworld on the same issue. Dave Lewis (yes, our Dave Lewis) wrote up my little issue over at CSO. Another Dave article at CSO: Find security flaw, go to jail? Favorite Securosis Posts Adrian Lane: Firestarter: The NSA and RSA. Despite looking and sounding like I am being pulled into a 4th dimension, my favorite this week is the inaugural Securosis Firestarter. Mike Rothman: Firestarter: The NSA and RSA. Yeah, everyone is going to pick Rich’s $500 screw-up post. But I am really excited at how our video podcast turned out. As long as we keep it short it will be a lot of fun to do in 2014. Mort: My $500 Cloud Security Screwup – Updated. James Arlen: Rich Mogull is the Most Honest Man in Infosec. Editor’s note: not really! Rich: Incite 1/8/2014: ReNew Year. Yep, new stuff coming – can’t wait to get it out there and see what works! Other Securosis Posts Security Management 2.5: The Decision Process. Mikko Hypponen Still Speaking at the RSA Conference Updated. Security Management 2.5: Evaluating the Incumbent. Security Management 2.5: Revisiting Requirements. Firestarter: The NSA and RSA. Favorite Outside Posts Adrian Lane: So You Wanna Boycott RSA Conference 2014. Why write this post again? Bill said it better. Mike Rothman: Don’t Tell Me You’re Busy. Thanks to our pal Jen (@mediaphyter) for reminding me of this classic post. We are all busy. But no one is too busy to return a call or text from a friend. And if you are, your priorities are screwed up. Dave Lewis: The 7 best habits of effective security pros. Mort: On Getting Naked in Antarctica. It’s not security related, but in honor of this week being so damn cold in the midwest & northeast… James Arlen: Applied Crypto Hardening – PDF Rich: How Netflix Reversed Engineered Hollywood. Some interesting big data lessons in here. Research Reports and Presentations What CISOs Need to Know about Cloud Computing. Defending Against Application Denial of Service Attacks. Executive Guide to Pragmatic Network Security Management. Security Awareness Training Evolution. Firewall Management Essentials. A Practical Example of Software Defined Security. Continuous Security Monitoring. API Gateways: Where Security Enables Innovation. Identity and Access Management for Cloud Services. Dealing with Database Denial of Service. The 2014 Endpoint Security Buyer’s Guide. Top News and Posts Snapchat hack results in 4.6 million accounts being posted online. Yahoo! Spread Bitcoin Mining Botnet Malware Via Ads. Video tells children it’s okay for TSA to molest them. So bad it’s awesome! TSA uses animated dogs as characters – if you own dogs, you know “Stop, Scream, & Pee” is more likely. Firm Bankrupted by Cyberheist Sues Bank via Krebs. Inside TAO. How Worried Should We Be About the Alleged RSA-NSA Scheming? Office 365 Token Vulnerability. A couple weeks old but a good read. Infographic: ISO 27001:2013 Changes Skipfish Scanner Used In Financial Sector Attacks Five Product Security Questions Nobody At CES Wants You To Ask. Blog Comment of the Week This week’s best comment goes to Jay, in response to Security Management 2.5: Evaluating the Incumbent. More good stuff here and sound analysis. I think we’ve done a good job identifying where the SIEM market is or should be going. Hope you intend to provide some sort of

This speaks for itself: An Open Letter to the Chiefs of EMC and RSA and Securing Smart Machines: Where We Are, Where We Want to Be, and Challenges I have confirmed from multiple sources that the session is still on the schedule, and he has not cancelled yet. Update: Mykko updated his post and he is now pulling out of all talks. He also says: While I am glad to see that many other speakers have decided to cancel their appearances at RSA 2014 in protest, I don’t want to portray myself as a leader of a boycott. I did what I felt I had to do. Others are making their own decisions. I’m glad he cleared that up. Share:

Update: Amazon reached out to me and reversed the charges, without me asking or complaining (or in any way contacting them). I accept full responsibility and didn’t post this to get a refund, but I’m sure not going to complain – neither is Mike. This is a bit embarrassing to write. I take security pretty seriously. Okay, that seems silly to say, but we all know a lot of people who speak publicly on security don’t practice what they preach. I know I’m not perfect – far from it – but I really try to ensure that when I’m hacked, whoever gets me will have earned it. That said, I’m also human, and sometimes make sacrifices for convenience. But when I do so, I try to make darn sure they are deliberate, if misguided, decisions. And there is the list of things I know I need to fix but haven’t had time to get to. Last night, I managed to screw both those up. It’s important to fess up, and I learned (the hard way) some interesting conclusions about a new attack trend that probably needs its own post. And, as is often the case, I made three moderately small errors that combined to an epic FAIL. I was on the couch, finishing up an episode of Marvel’s Agents of S.H.I.E.L.D. (no, it isn’t very good, but I can’t help myself; if they kill off 90% of the cast and replace them with Buffy vets it could totally rock, though). Anyway… after the show I checked my email before heading to bed. This is what I saw: Dear AWS Customer, Your security is important to us. We recently became aware that your AWS Access Key (ending with 3KFA) along with your Secret Key are publicly available on github.com . This poses a security risk to you, could lead to excessive charges from unauthorized activity or abuse, and violates the AWS Customer Agreement. We also believe that this credential exposure led to unauthorized EC2 instances launched in your account. Please log into your account and check that all EC2 instances are legitimate (please check all regions – to switch between regions use the drop-down in the top-right corner of the management console screen). Delete all unauthorized resources and then delete or rotate the access keys. We strongly suggest that you take steps to prevent any new credentials from being published in this manner again. Please ensure the exposed credentials are deleted or rotated and the unauthorized instances are stopped in all regions before 11-Jan-2014. NOTE: If the exposed credentials have not been deleted or rotated by the date specified, in accordance with the AWS Customer Agreement, we will suspend your AWS account. Detailed instructions are included below for your convenience. CHECK FOR UNAUTHORIZED USAGE To check the usage, please log into your AWS Management Console and go to each service page to see what resources are being used. Please pay special attention to the running EC2 instances and IAM users, roles, and groups. You can also check “This Month’s Activity” section on the “Account Activity” page. You can use the dropdown in the top-right corner of the console screen to switch between regions (unauthorized resources can be running in any region). DELETE THE KEY If are not using the access key, you can simply delete it. To delete the exposed key, visit the “Security Credentials” page. Your keys will be listed in the “Access Credentials” section. To delete a key, you must first make it inactive, and then delete it. ROTATE THE KEY If your application uses the access key, you need to replace the exposed key with a new one. To do this, first create a second key (at that point both keys will be active) and modify your application to use the new key. Then disable (but not delete) the first key. If there are any problems with your application, you can make the first key active again. When your application is fully functional with the first key inactive, you can delete the first key. This last step is necessary – leaving the exposed key disabled is not acceptable. Best regards, Alex R. aws.amazon.com Crap. I bolted off the couch, mumbling to my wife, “my Amazon’s been hacked”, and disappeared into my office. I immediately logged into AWS and GitHub to see what happened. Lately I have been expanding the technical work I did for my Black Hat presentation, I am building a proof of concept tool to show some DevOps-style Software Defined Security techniques. Yes, I’m an industry analyst, and we aren’t supposed to touch anything other than PowerPoint, but I realized a while ago that no one was actually demonstrating how to leverage the cloud and DevOps for defensive security. Talking about it wasn’t enough – I needed to show people. The code is still super basic but evolving nicely, and will be done in plenty of time for RSA. I put it up on GitHub to keep track of it, and because I plan to release it after the talk. It’s actually public now because I don’t really care if anyone sees it early. The Ruby program currently connects to AWS and a Chef server I have running, and thus needs credentials. Stop smirking – I’m not that stupid, and the creds are in a separate configuration file that I keep locally. My first thought was that I screwed up the .gitignore and somehow accidentally published that file. Nope, all good. But it took all of 15 seconds to realize that a second test.rb file I used to test smaller code blocks still had my Access Key and Secret Key in a line I commented out. When I validated my code before checking it in, I saw the section for pulling from the configuration file, but missed the commented code containing my keys. Crap. Delete. Back to AWS. I first jumped into my Security Credentials section and revoked the key. Fortunately I didn’t see any other