The revelations of the Snowden Leaks and other events in modern internet times have resulted in a need for developers and security professionals working on start-up companies to rethink not just security policies and procedures but overall architecture more broadly. Cryptographic systems in communications systems have seen the largest architectural changes. However, changes are also required in data storage architecture and even networking architecture. This talk will discuss means and methodologies for building secure, robust, and resilient start-up computing architectures. Common attacks that impact startups, data compromises, and DDoS attacks will be discussed. The impact of the required adaptations in infrastructure and software design on existing common business models, like AdRev, will be touched on.

2. Алекс Бреннен
Криптография, защита данных и
безопасность для стартапов в «пост-
сноуденовской» эпохе
Консультант

3. About Me...
* Cypherpunk (1990's Definition)
* Consultant (ProtonMail, various others...)
* MIT SysAdmin (10+ years)
* Last Time I Gave A Talk About Computer Security I Was Not Invited Back
Watching MIT presentations taught me: When presenting... don't get too technical.
Instead, massively challenge everyones' thinking (you'll energize and motivate
them).
• Views and opinions presented during this presentation are my own and do not reflect my current or previous employer's
• (in fact they may conflict with them)

4. A Russian Painting
Countess Mordvinov's Forest (1891) by Ivan Shishkin

5. What Snowden (And Others) Revealed
* Unencrypted Communications Are Intercepted
* Cryptographic Standards And Systems Have Been Subverted
* Uncompromised Cryptographic Systems Are Attacked Directly (SIM Attack)
* Systems and Networks Are Attacked Directly
* US Government Works Closely With Vendors
* Data Is Collected And Warehoused Indefinitely On Everyone
* Large Cache of Hacking Tools And Vulnerabilities

6. Snowden Showed How Bad Things Are
* US Government Has Made “Cyber” Capability a Priority
* Subverting Open Standards (Cryptography/Protocols/Etc)
* Purchasing Vulnerabilities and Perhaps Creating/Introducing Them
* Large USD (Billions) Budget For Offensive Research
* Evidence of Use of CyberAttacks in International Disputes
* A Untargeted Drag Net (Fear of Missing the Next Big One)
* Primary Source of US Intelligence is Now “Cyber” Capabilities
* NSA Growth Unparalleled In Last Decade
* “Golden Age Of Intellegence” - GEN Michael Hayden, Frm. Dir. NSA
* Widespread Adoption of Cell Phones and Social Media by People
* Global Corporate Pivot to “Big Data”

7. NSA/State Actor Capabilities vs Other Hackers
Due to Legal Support and Massive Budget NSA/State Actors Will Always Be in Own
Class
Unmatched Primary Capabilities
* Telecommunications Intercepts
* Telecommunication Injections
* Cryptographic Infrastructure Subversion
Hacking/Compromise
* Traditional Methods (Buffer Overflows, etc)
* Algorithm/Cryptographic System Compromise (SSH/DH - POISONNUT)
* Tools and Techniques are Leaking!

8. But, We've Been Getting Better Right?
Virtualization/Compartmentalization
* Virtualized Dynamic Memory Environments (Java, etc)
* Virtual Machines (Operating System Images)
* Containers (Sub-OS Application Images)
* VPNs/VLANs
Helpful, but...
* Systems Still Need To Talk To Each Other
* New Class of HyperVisor Attacks

9. Engineering Lesson: We Cannot Stop Them
We need to engineer our systems with the expectation that we cannot stop hackers
from penetrating them.
30 Years Ago: Buffer Overflows, Off-By-1, SQL Injection, etc.
20 Years Ago: Buffer Overflows, Off-By-1, SQL Injection, etc.
10 Years Ago: Buffer Overflows, Off-By-1, SQL Injection, etc.
Today: Buffer Overflows, Off-By-1, SQL Injection, etc.
Tomorrow: (More of the Same).

10. Engineering Lesson: No Really, We Cannot Stop Them
● Seriously, We Cannot Stop Them
● Almost No One Was Protected From HeartBleed
* Maybe there was one or two Active Firewalls?
* They got OpenBSD!

11. Patches Can Take A Long Time
Zeroday Bugs Can Exist For Years Before Discovery
* A Study Found Linux Kernel Bugs Take Average Of 857 Days After Discovery to Be
Fixed.
* The Same Study Found Windows Core OS Vulnerabilities Take 375 Days After
Discovery To Be Fixed.
Zerodays Can Exist For Years, or Even Decades, Before Discovery
* Linux Has Seen Exploitable Security Flaws Exists For As Long As 11 Years With Out
Detection and Correction
Patching Can Be Difficult Or Impossible For End Users
* Equifax (Apache Struts)
* Unmaintained OpenSource Software
Study By TrustWave (2012)

12. TrustWave 2012 OS Vulnerability Study

13. So What Should We Do?
* Encrypt Valuable Data
* Aggressively Limit Account Privilege
* Limit What You Store
* Eliminate Single Points of Security Failure
* Metrics, Metrics, Metrics
* Backups

14. Encrypt Valuable Data
Attackers Are Most Often After Data
* Identity Data/Financial Data (Equifax, etc)
* E-Mail/Text/Photo Leaks (Sony, Celebrities, etc.)
* Industrial Espionage (Big 5 Defense Contractors, Oracle, Akamai, Hedge Funds, etc.)
Companies Aren't Encrypting Yet
* Some Large Companies Are Just Now Starting To Do Encryption At Rest
* Encryption Can Be Hard (For Example: Password Storage)
Don't Let Your Compromise Be Your Customer's Compromise
* Be Able to Lose Your Systems With Out Losing Customer Data
Encryption Doesn't Have to Be Difficult! Use An OpenSource Toolkit.

15. Encryption Best Practices
OK System
* Data Encryption With Company Controlled Key (AES128/AES256/ECC)
* Encryption of All Data During Transit (TLS 1.2/TLS 1.3)
* One Way Hashing Of Unneeded Data (Blake2, etc)
Good System
* Data Encryption With Company Managed Customer Controlled Key
(openPGP/AES128/AES256/ECC)
* Encryption of All Data During Transit with PFS (TSL 1.2/TLS 1.3)
* One Way Hashing of Unneeded Data (Blake2, etc)
Great System
* Data Encryption With Customer Controlled Key (AES128/AES256/ECC)
* Encryption of All Data During Transit with PFS (TSL 1.2/TLS 1.3)
* One Way Hashing of Unneeded Data (Blake2, etc)

16. Aggressively Limit Account Privilege
SQL Dump - Most Common Way For Compromised Data To Circulate
Prevent SQL Dumps
* Have Granular Role Accounts (Authentication/Metadata/Customer Data)
Shell Accounts Are Always A Danger
* Avoid Using/Sharing Root Account (Create Role Accounts, Use sudo)
* Use Binary Programs When Possible (sudo to limit access)
Database Accounts And Application Accounts Should Also Be Limited
* The Principal of Least Privilege
* Limit Database Account Privilege To Minimum Necessary (Read Only)
* Even Internally In Your Own Applications

17. Limit What You Store And Collect
If You Do Not Have The Data, Hackers Will Not Come For It
Avoid Storing Personal Data When Ever Possible
* For Example: If Using SMS Verification, Store Salted Hash of Verified Phone Number (aka
“Selector”)
* Third Party Vendor For Credit Cards, Bank Account Details, etc.
Aggressively Expire Data After You No Longer Need It
* Liability Laws Will Probably Be Next For Ukraine (After Criminal)
When Storing Data Encrypt It
* Symmetric Encryption With Key Stored In Code (OK)
* Symmetric Encryption With Key Stored In Protected RAM/File/HSM (Better)
* PGP Public/Private Keypair With Private Key Air Gapped (Best)

18. Eliminate Single Points of Security Failure
No Single Compromised System or Piece of Software Should Compromise Your Entire
Infrastructure
Firewall and VPN Isolation is Important
Consider Security Carefully When Building or Deploying A DevOps System
Different Authentication Credentials (Passwords, Two Factor Code, etc) on Everything
Full Access Is Efficient. Efficiency Is Dangerous.

19. Monitoring and Metrics, Metrics, Metrics
The State of The Art in Monitoring is Active Kill Systems.
For Start-Ups Best Practice is Monitoring and Metrics
* Put Monitoring on Everything (OpenFlow, Log Analysis, Bandwidth, Account Activity)
* Use Statistics and Metrics to Catch Potential Problems
* Bandwidth Usage Abnormality – Possible Data Exfiltration
* Disk I/O Abnormality – Possible Ransomware Infection
* Unusual Traffic From Certain IPs – Botnet Activity
* Unusual Account Activity – Possible Employee Compromise
Monitoring Your Systems Is Critical To End Point Security.

20. Barrier For Proof Of Work
Cryptographic Systems Will Eventually Be Broken
Some Systems May Already Be Broken (Historically The Case)
The Idea is to Create a Barrier that Stops Hackers and Companies From Accessing Data
They Shouldn't. Not Necessarily State Actors.

21. DDoS Attacks
Attacks Have Become Large Enough To Knock Entire Countries Off Line For Extended
Periods
* Consider Upstream Fiber Capacity of Any Networking Infrastructure
* Infrastructure Is Changing (Architecture, Throttling, Traffic Analysis, etc)
Any Large Site Will Need To Deploy A BGP Based Traffic Scrubber
Think About API DDoS Possibilities When You Design API's, Communication Systems,
and Even Basic Systems Like Search
DDoS Attacks Are Frequently A Distraction From Another Attack
A Large DDoS Can Quickly Bankrupt Your Company.

22. Start-Up Revenue Models
There Are Workable Alternatives To AdRev!
Subscription Model
* Pay Monthly (Recurring Fee Covers Resource Usage. Example: ProtonMail)
The Utility Model
* Pay For Resource Usage (Storage, Network, CPU. Example: AWS)
Alt-AdRev Broadly Targeted/CPA (Cost Per Actions)
* This Worked For Early Internet and For Decades With TV and Radio
The Snowden revelations likely changed what is possible in terms of business
models.

23. Will They Work For Ukrainian Start-Ups?
Most Common Areas of Competition Are In Local Language Verticals
* Company X for Country Y or Language Z (Examples Yandex, VK)
Current Incentives Are Around Ease of Use And Cultural Fit
Consider Building Companies and Products That Offer Security and Privacy Incentives
* A Good Product With Good Enough Incentive May Break Out of Geography
* Local Laws May Be Used For Arbitrage

24. In Summary...
* End to End Encryption - If Possible
* But, At Least Client Side Encryption
* Decentralized/Ephemeral Keys and Primitives
* Data Retention As Risk Rather Than Reward
* Auto-expiration/Auto-wipe
Cultural Change is Already Happening!

25. Alex Brennen
vab@protonmail.ch
Thank you, for your attention!
(Спасибо за внимание!)