We’re well past a month into the COVID-19 shutdown, and I noticed that fewer and fewer trains were running on Regional Rail each day. I knew that SEPTA had decreased their service due to less riders, but I wondered just how strict the service cuts were. I also wondered if more or perhaps less trains were running on time.
I started off by firing up Splunk Lab then went for a walk while it took 15 minutes or so to load the data up. I came back, and decided to see where we were:
That’s well north of 60 million data points. While I could crunch that data as-is, it would take longer for me to run my subsequent queries as well as look for trends in the data. I ended up writing a couple of scripts to summarize that data on a daily basis, so that I can get a bucketed breakdown of late trains for the entire day. We’ll get back to that bucketing later, because I first want to talk about train volumes.
I figured that with the perceived dropoff in service, I could look at how many distinct trains (identified by train number) each day. Sure enough, there was a drop off in train service levels:
Things started to get serious the week of Monday, March 16th. In fact, that was the last day of “normal” service on Regional Rail. Starting on Tuesday the 17th, the number of trains per weekday went from nearly 500 to about 362, with the weekends unaffected.
With the release of SEPTA’s new app, I’ve suddenly been flooded with questions about their API. People wanted to know how stable it was.
Well, I don’t work for SEPTA, which means I don’t have insight into their operations, but I can perform some analytics based on what I have, which is approximately 18 months of Regional Rail train data, read every minute by SEPTA Stats.
This is all of the data that I have in Septa Stats currently:
Events Since Inception: 26,924,887 events
First Event: Mar 1, 2016 12:00:01 AM
Last Event: Nov 16, 2017 10:33:53 PM
That’s way more events than minutes in that timeframe, and the reason for that is each API query is split into a separate event for each train. So if an API call returns status for 20 trains, that gets split into 20 different events. This is done because Splunk has a much easier time working with JSON that isn’t a giant array. 🙂
I’m pleased to announce that dashboards are now available on train views.
Prior to the introduction of the dashboard, it was difficult to tell if a train was running, what route it was on, and what station it was at. This new dashboard makes use of the “latest” API endpoint described in the previous post to provide a snapshot of the current status of the train.
As a service to the Philly tech community (and because folks asked), I took notes at tonight’s presentation, called “Security Practices for DevOps Teams”. It was presented by Chris Merrick, VP of Engineering at RJMetrics.
Security is a “cursed role”
…in the sense that if you’re doing a really good job as a security engineer, no one knows you exist.
It isn’t sexy
It’s hard to quantify
It’s never done
As DevOps engineers, we are all de facto security engineers
Some tips to avoid ending up like this [Picture of a dismembered C3PO]
Obscurity is not Security
“A secret endpoint on your website is not security”
“Don’t rely on randomness to secure things”
Do not give more privileges than are needed
If you talk to an insecure system, you’re at risk
Breaking into datacenters
Any vector that comes through an application you developed
Applications you didn’t write
Phishing, social engineering
Authentication is who you are
Authorization is what you can access
Don’t access production directory
Good news: this is our job anyways
Don’t spread private keys around
Don’t put in your Dropbox
Don’t let it leave the machine you generated it on
Use SSH agent forwarding
ssh -A you@remote
Don’t use shared accounts
Be able to revoke access quickly
Time yourself. Go.
We use Amazon OpsWorks to help us achieve these goals
Chef+AWS, with some neat tricks: simple autoscaling, application deployment, and SSH user management
“Logs are your lifeline”
When you get into a high pressure security investigation, you start with your logs
Capture all authentication events, privilege, escalations, and state changes.
From your Os and all running applications
Make sure you can trust your logs
Remember – they’re your lifeline
Have a retention policy
We keep 30 days “hot”, 90 days “cold”
Logging – ELK
We use ELK for hot log searching
Kibana creates logs and lets you monitor your application in real time
Keep unencrypted secrets out of code
Otherwise, a MongoLab exploit becomes your exploit
Don’t keep old code around
Make deployment and rollback easy
More good news: this is our job anyways
When dealing with a security issue, the last thing we need a “hard last step” in order to get the fix out
Don’t use your root account, ever.
Set a long password and lock it away
Set a strong password policy and require MFA
Don’t create API keys where API access isn’t needed
Same goes for a console password
Use Managed Policies
To make management easier
Use Roles to gran taccess to other systems
No need to deploy keys, auto-rotates
IAM Policy Pro Tips
Don’t use explicit DENY policies
Keep in mind that everything is denied by default
Don’t assume your custom policy is correct just because it saves – the interface only confirms the JSON is valid
Use the policy simulator
Know Thy Enemy
People are out there scanning for AWS keys – treat your private key like a private SSH key
Earlier tonight, I had the pleasure of attending a presentation from Chris Munns of Amazon at the offices of First Round Capital about scaling your software on AWS past the first 10 million users. I already had some experience with AWS, but I learned quite a few new things about how to leverage AWS, so I decided to write up my notes in a blog post for future reference, and as a service to other members of the Philadelphia tech community.
Without further preamble, here are my notes from the presentation:
Each year, The Dorsai Irregulars have their own annual convention known as “Dorsai Thing”. It is a weekend long event, held in a different city each year, where we all gather, socialize, and hold our semi-annual business meeting. This year, it was held in Phildelphia, and it fell on my shoulders to run the event, dubbed “Liberty Thing” While I’ve worked at plenty of conventions before, this was the first one where I was effectively the Con Chair. This was an entirely new thing for me, and I wanted to write a blog post about some of the things I learned during the experience.