chandler howell's aws chicago user group presentation "iot security in aws"l
Post on 06-Apr-2017
116 Views
Preview:
TRANSCRIPT
Topic: IoT/Security/TOC/#
{{ “Message”:“Background,The Ecosystem,Precursors,AWS Overall,Infrastructure,Multi-Tenancy,Transport,Clients,LWT,Resources”}
}
IoT/Security/Background/WhoAmI
I’m Chandler HowellDirector of Engineering at Nexumchandler@nexuminc.com@chandlerhowell on Twitter
Nexum is a Network & Security Reseller & Consultancy
Headquartered in ChicagoPresence East of the Mississippi Riverhttp://nexuminc.com
Iot/Security/Background/Why
Hopefully, to have wasted your time
Started talking IoT Security in 2015How it suckedWhy it suckedWhy it mattered
IoT/Security/Ecosystem/#
AWSAWS IoTInfrastructure
TransportRESTful HTTPWebSocketMQTT
ThingsSensorsDevices
ClientsAppsAPI’sWeb portals
Gotta Secure ‘em All!
Iot/Security/Precursors/HowToFAIL
What am I hoping you’ll avoid?
FAILURE
Harming peopleBeing in the newsDevice recalls/updatesGetting suedCorporate bankruptcyBringing bad products to market
IoT/Security/Precursors/Policies
You’re in the Data Business nowWhat data do you collect?How long do you retain it?Who owns the data you collect?
Do you have a published Privacy Policy?Have you calibrated your business model with it?Does it cover both Internal & Third Party Use, Sharing and Disclosure?
Do you have a published Service Level Agreement?
Do you have Incident Response & Disaster Recovery Plans?
IoT/Security/Precursors/Assumptions
If you must assume, assume things will go wrong.
* Connectivity will fail* Network* Device Association
* Vulnerabilities will be found* Devices will be compromised* Keys/Credentials will be compromised* Retail (client)* Wholesale (server keys)
* Data might be breached or destroyed
How will each of these affect...your customers?...your product?...your company?
IoT/Security/Precursors/Challenges
How will you…* Push updates to Things
* When would you force an update?* Cryptographically verify those updates
* Track versions* Deal with version incompatibilities
* Deal with potential downtime
IoT/Security/Precursors/Transport
* How much data can you lose to outages?* How much data can you queue?
* If you can’t publish to a Thing...* What telemetry is lost?* What functionality is lost?
* How will you handle network limits* Blocking MQTT* Blocking HTTPs* Blocking un-inspected SSL/TLS
IoT/Security/AWS
Expect to use LOTS of services* Manage access through IAM Policies & Roles* Segment where it makes sense* Consider CRUD needs for all access * (Create, Read, Update, Delete)
AWS Provides some features by default* DDoS Protection
IoT/Security/AWS/EC2
* This is a great place to get pwned* “Traditional” IT brings Traditional
problems
* ALL SERVERS SHOULD BE EPHEMERAL* “Pets vs. Cattle”
* Amazon Inspector is your friend* https://aws.amazon.com/inspector/ * Security Scanning* Can be automated with Lambda & SNS* Ticketing, e.g. into Jira
IoT/Security/AWS/Monitoring
You can’t find what you don’t look for
Log & alert changes to:* Running instances* Policies* IAM Roles* Accounts* Security Groups* Billing Events* Workload spikes* Errors & Exceptions
IoT/Security/AWS/HowToWin
* Harden the environment* Delete the Root Access Keys* Enable Multi-Factor/Strong Authentication
* Adhere to the Principle of Least Privilege* Don’t just hand out Permissions* RTFM on Policies & Permissions* AWS Provides Sample Policies
* Don’t forget your processes* User Management* IT Inventory & Asset Management* Vulnerability & Configuration Management
IoT/Security/AWS/HowToWin/2
Minimize your Attack Surfaces* Only expose Public Services to the Internet* Segment where it makes sense* Limit internal access to Production
* Make use of AWS’ IAM & RBAC* RBAC is a de facto inter-service firewall
Use real remote access* Direct Connect* Layer 3 VPN* Bastion Host/Jump Box* Assuming you absolutely HAVE to access
instances directly
IoT/Security/AWS/Infrastructure/PSA
Public Service Announcement:
Don’t put your infrastructure raw on the Internet!
Don’t be a…MongoDB or ElasticSearch
Mass hack victimVtech Hack VictimCloudPets Hack Victim
IoT/Security/AWS/MultiTenancy
Assume you need multi-tenancy…* How distinct must the segregation be?* Separate accounts* Cumbersome, but most effective
* Separate data stores* Do-able, but shifts complexity into the
business logic* Common data stores with key fields* Best option if it is an option
IoT/Security/Multi-Tenancy/IAM
* Not complete or by default in all services
* Fine-grained access control through AWS Identity & Access Management (IAM)
But…some Control Plane calls are not (yet)e.g. “list-things” will show all devices,
not just a tenant’s devices* Wrap that API to filter to just the
tenant via device registry
IoT/Security/Multi-Tenancy/HowToWin
* Define Requirements up front* How much segregation is enough?
* Review each service’s capabilities* Make sure you solve before you commit
* Include tests for cross-tenant failure* Can you CRUD resources you should not be
able to?
IoT/Security/AWS/Lambda
* This is where the magic happens* Good Magic* like working code
* Bad Magic* AppSec vulnerabilities
* Resources like OWASP apply here, too* http://www.owasp.org* Open Web Application Security Project* SANS Also has great AppSec training* http://sans.org
IoT/Security/AWS/Transport/+
* 3 Options within AWS* HTTP (RESTful)* WebSocket* Message Queue Telemetry Transport (MQTT)
IoT/Security/Transport/HTTP
* HTTP* POST to a RESTful API* Only scales so far* Included for completeness
* <AWS IoT Endpoint>/topics/<url_encoded_topic_name>?qos=1* Uses AWS Signature Version 4* Add either a Query String param or an
Authorization: headerGET https://iam.amazonaws.com/?Action=ListUsers&Version=2010-05-08 HTTP/1.1Authorization: AWS4-HMAC-SHA256 Credential=AKIDEXAMPLE/20150830/us-east-1/iam/aws4_request, SignedHeaders=content-type;host;x-amz-date, Signature=5d672d79c15b13162d9279b0855cfba6789a8edb4c82c400e06b5924a6f2b5d7content-type: application/x-www-form-urlencoded; charset=utf-8host: iam.amazonaws.comx-amz-date: 20150830T123600Z
IoT/Security/Transport/WebSocket
* WebSocket tunnels MQTT over HTTP(s)* Good for passing firewalls* Runs over port 443* Uses the HTTP UPGRADE verb
* Also AWS uses Signature Version 4* URL Format:
wss://<endpoint>.iot.<region>.amazonaws.com/mqtt
* Best if you have a hub forwarding traffic
* Either no MQTT allowed* or older, crypto-incapable devices
IoT/Security/Transport/MQTT
* Publish-Subscribe protocol* 1st implementation 1999* Designed for high-latency, low bandwidth* Lightweight* Bandwidth* CPU
* Can be secure, but can be Not Secure, too
IoT/Security/Transport/MQTT/QoS
* 3 Quality of Service (QoS) Options* 0 – At most once * Best Effort* No retry, no acknowledgement
* 1 – At least once* Retry until acknowledgement received* May result in multiple deliveries
* 2 – Guaranteed single delivery* Full send-ack transaction & queueing
IoT/Security/Transport/MQTT/Authentication
* Multiple Options* No Authentication (Don’t do this)* Topic-based Pseudo-auth (Another NOPE)* Username/Password (Dont’ do this either)* X.509 Certificates (Do this)* AWS makes this easy
IoT/Security/Transport/MQTT/HowToFail
* Authentication* No Authentication* Weak Authentication
* Not encrypting Traffic* MQTT+TLS For The Win* (Unless absolutely necessary)
IoT/Security/Transport/MQTT/HowToWin
* Use X.509 Certificates for Authentication* Always use TLS if possible* Use AWS IAM to define device roles* Follow Principle of Least Privilege* Test for Information Leakage* e.g. aws iot list-devices in multi-
tenant environments* If you have insecure legacy devices, use
a broker for secure upstream transport
(Yes, that’s the username & password being sent in the clear!)
IoT/Security/Transport/MQTT/PSA
Public Service Announcement:
Username & Password are even less of your friend than usual
IoT/Security/Clients
* Researcher focus has largely been on clients* Soft targets* Riddled with Amateur Hour vulnerabilities* Weak machines * Under their physical control* Fewer legal issues
* Ecosystem testing still the realm of authorized testers* They don’t generally publish* So less data to to assume against
IoT/Security/Clients/HowToFail
* A few pitfalls to avoid* Use of no/default credentials* Re-use of keys or credentials* Hard coding credentials* Assuming a friendly deployment environment* Running unnecessary services* Especially network services
* Not using signed/secure images
IoT/Security/Clients/HowToWin
* Incorporate security into your design* Threat Model* Educate yourself on AppSec
* Scan/Attack your services & device ports* Dynamic Analysis tools
* Run Static Analysis tools on your source code* Or at least include failure-mode tests
* Consider credential storage on the client* How hard is credential (key) compromise?* What do those keys get you?* Do you leak credentials, e.g. Wi-Fi?
IoT/Security/LWT
I’ve asked you a lot of questions, so I guess it’s only fair to let you ask me some.
IoT/Security/Resources
* Security & Identity for AWS IoT * https://docs.aws.amazon.com/iot/latest/developerguide/iot-security-identity.html
* Things I wish I’d known before I started working with AWS* https://wblinks.com/notes/aws-tips-i-wish-id-known-before-i-started/* especially this change monitoring script
* https://s3.amazonaws.com/reinvent2013-sec402/SecConfig.py
* AWS Security Blog Post: Automatic Remediation with AWS Inspector* https://aws.amazon.com/blogs/security/how-to-remediate-amazon-inspector-security-findings-automatically/
* MQTT Security Fundamentals* http://www.hivemq.com/mqtt-security-fundamentals/
* AWS IoT Protocols* https://docs.aws.amazon.com/iot/latest/developerguide/protocols.html
* How to bridge Mosquitto MQTT Broker to AWS IoT* https://aws.amazon.com/blogs/iot/how-to-bridge-mosquitto-mqtt-broker-to-aws-iot/
* Multi-Tenant Storage with DynamoDB* https://aws.amazon.com/blogs/apn/multi-tenant-storage-with-amazon-dynamodb/
* AWS Access Management* https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html
top related