Upload
aleksandr-yampolskiy
View
6
Download
2
Embed Size (px)
DESCRIPTION
What CTOs need to know about Security, Dr. Aleksandr Yampolskiy is CTO at Cinchcast In this talk, Aleksandr Yampolskiy will discuss what CTOs need to know about security. No company is small enough not to worry about getting hacked. For a small to mid-sized business getting hacked may be lethal, as they will have to spend time to recover from the breach and repair their customer reputation. Alex will discuss a simple score that you can use to calculate if your company is secure, as well as various techniques that you can use to stay protected without spending any money. http://www.ctothoughts.com/2011/10/why-smal... Dr. Aleksandr Yampolskiy is the CTO at Cinchcast, a New York based startup which allows companies to share, measure and monetize audio content. Prior to Cinchcast, Alex was a Head of Security and Compliance at Gilt Groupe companies, as well as held various lead roles in Goldman Sachs, Oracle, and Microsoft. He's been cited in New York Times, Observer and other media. He is a published author and speaks regularly on security and software development.
Citation preview
What CTOs Need to Know About Security
Aleksandr Yampolskiy
Who Am I?
• Dr. Aleksandr Yampolskiy • CTO of Cinchcast, BlogTalkRadio, and Cinch.FM companies
that provide solutions to create, share, measure, and monetize audio content.
• Previously global head of security and compliance for Gilt Groupe companies, in charge of securing IT infrastructure, secure architecture, PCI/SOX compliance.
• Various leadership roles in Goldman Sachs, Oracle, Microsoft building scalable, enterprise software for IDM, SSO, AuthN/AuthZ.
• Ph.D. in Cryptography • Hobbies: chess, Edward Hopper, Ray Bradbury, martial arts,
lately foosball and coffee.
Email: [email protected]: @ayampolskiyBlog: http://www.ctothoughts.com
Company Overview
• Cinchcast provides cloud-based software and services for creating, distributing, measuring and monetizing voice-based content• BlogTalkRadio is a consumer-based media property
Founded in 2006 ~30 Employees 15 of them in Tech HQ in New York, NY Millions of pageviews a
day Powering over 1,500
hours of content creation every day
Confidential © 2011 Cinchcast - All Rights Reserved 3
BlogTalkRadio : Largest Audio Social Network(for consumers)
The Cinchcast Platform(for enterprises)
Confidential © 2011 Cinchcast - All Rights Reserved 5
6
Security: Bird’s Eye View
EncryptionEncryption
CertificatesCertificates
SignatureSignature
SSLSSL
Security ToolboxSecurity Toolbox
DL(gDL(gxx))Fact(p*q)Fact(p*q)
Hard problemsHard problems
Prob[Prob[
AttackAttack
] ≤ ] ≤ ɛɛ
Proof of securityProof of security
......
7
Building Secure Systems
…
Looks safe
to me
8Building Secure Systems
• All is well until it starts raining…
Hacking is easy. Just ask my friend Sabu
Evolution of the attack
Evolution of the hacker
Our Approach
• “Be brief, be bright, be gone”• Don’t go chasing hot technologies of the
day. Instead ‘mitigate your top problems’• “Onion security” : protections at all
levels.• Achieve “essential”, then worry about
“excellent”.• Build security into the software
development lifecycle.
Love And Other Drugs
RULE #1 : GET THE EXECUTIVE BUY-IN
Business projects
Security projects
“IT security needs a philosophy and only a CEO can make that kind of a decision.” -Hyundai Capital CEO Ted Chung
Sometimes You Should Not Care
Risk = Threat * Vulnerability * Cost
• Threat = likelihood that a security event will happen – Threat of purse snatching by breaking car window with a
heavy object was zero nationwide in 1960 (never happened).
– The threat became significant in Miami in 1970.
• Vulnerability = likelihood that a target is vulnerable to that threat– Most car passenger windows are always breakable by
heavy bricks.– No threat until 1970 implies no risk until 1970.
• Cost = how much money you lose if a threat succeeds.– Cost of a car window for Mercedes Benz SLK 230 is
$226. – For a Hyundai Sonata, the cost is $99.
Moral of the Story
• You have to adopt a proper security posture for your company.
• What works for a large investment bank may not work for a small startup.
RULE #2: MAKE SURE NO WEAK OR DEFAULT PASSWORDS ARE USED
• Verizon Data Breach Report (2011)
Majority of attacks resulted from weak or default passwords.
Hackers are Well Aware of That Fact
THC HYDRA
CUPP
Default password lists
CREATE A STRONG PASSWORDProtect your data and system access from guessing and attacks!
KEYS TO A STRONG PASSWORD
LENGTHAt least 7 characters in length
COMPLEXITY• Uppercase letters
• Lowercase letters
• Numbers
• Symbols
RANDOMNESS• Use a song title, affirmation, popular phrase, or interest
• Mix in other characters to add complexity
I CAN EAT CANDY EVERY SINGLE DAY = iCEc@24x7!
EXAMPLE
RULE #3: SECURITY AWARENESS TRAINING
• Organizations are too focused on security controls/software, but the weakest link is people.
• Tell a personal story. Show how hacking happens.• Make sure security awareness training is mandatory
(exec buy-in helps!)
Social Engineering
• Gather Information• Spoof phone call “Hello, I’m a new
consultant. Alex is offsite today but he asked me to call you.”
• Phishing email• Attack while guard is down
RULE #4 : INSTITUTE SECURE CODING TRAINING
• 95% of web apps have vulnerabilities– Cross-site scripting (80 per
cent)– SQL injection (62 per cent)– Parameter tampering (60 per
cent)– Cookie poisoning (37 per
cent)– Database server (33 per
cent)– Web server (23 per cent)– Buffer overflow (19 per cent)
Hamster Wheel of Pain
• Developers write code, we find security bugs, prioritize them with PMs, fix them. Lather, rinse, repeat.
There Has To Be a Better Way
• Institute mandatory secure coding training for all developers.
• Fewer bugs, everyone is happy.
• Establish SLAs on fixing security bugs. Blocker security bugs always take priority over any business projects.
Measure Your Progress
•Create a Security category in your bug tracking tool.
•Measure the time to fix security bugs. Measure their amount.
•Plenty of free web app security tools (YASCA, WebScarab, Skipfish, Watcher plugin)
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
0-10 11-30 31-60 60+
SLA for Security Jira TicketsPriority: Blocker
The only rule you need to remember: “Validate All Input”
• Input validation failures are behind most common security vulnerabilities (buffer overflows, SQL injection, XSS, log forging).
• Input can come from many sources (HTML forms, query strings, environment variables, data files, shared memory, …)
• Always validate user input on the server-side before acting on it.
• Regexps are your friend– In RoR, validates_format_of :email :with => /^(+)@((?:[-a-z0-9]+\.)
+[a-z]{2,})$/– In Java, if (name != null && name.length() < 15 &&
name.matches(“\\w+”)) { … }
Cross-Site Scripting
• Cross-Site Scripting (XSS) attacks occur when• Data enters web app from untrusted source• Data is included in dynamic content that is sent to a user
without being validated for malicious code.
DEMO
SQL Injection
• SQL injection aims to influence database queries by manipulating input params.
• Example:– $check = mysql_query("SELECT Username, Password FROM Users WHERE
Username = '".$_POST['username']."' and Password = '".$_POST['password']."'");
– What if a user enters ‘OR 1=1 #’ as the name?
DEMO
RULE #5 : HARDEN YOUR SYSTEMS WITHOUT SPENDING MONEY
• Ensure sensitive apps are behind VPN (Admin, Jira, Wiki, QA, etc.)
• Harden bastion hosts, and create a uniform hardened OS image.
• The less doors you have, the less ways there are to get in.
• Most security tools are free– Intrusion Detection System: SNORT, AIDE, …– A/V : Immunet– Static code analysis: YASCA– Dynamic code analysis: Skipfish– Network scanners: Nmap, wafw00f, etc.
Example web environment
Webserver
Web app
Web app
Web app
Web app
transport
DB
DB
Appserver
(optional)
Internet DMZ Protectednetwork
Internalnetwork
Securing the application
Input validation Session mgmt Authentication
Authorization Config mgmt Error handling
Secure storage Auditing/logging
Securing the networkRouter
Firewall
Switch
Securing the hostPatches/updates Accounts Ports
Services Files/directories Registry
Protocols Shares Auditing/logging
Meet Dr. Virginia Apgar
Y-Chart to assess company’s security
SIGN 0 1 2
Executive buy-in None Some type of buy-in Buy-in at the board level
No weak or default passwords Many weak passwords or default ones
Some weak passwords here and there
Few weak passwords or 2-factor auth everywhere
Security awareness None Some people are trained Everyone is trained and proactive
Secure coding None Some developers are trained All developers are trained and code is regularly tested
Hardened systems None Some servers and workstations are hardened
All servers and workstations are hardened
Why are we building fragile apps?
• Complexity.• Poor testing methodologies (for example, few tools
for Ruby).• Business demand to rush to market.• Programmers are optimists. Expect well-behaved
users.• Mismatch between agile development and security
assurance.
What should we do?
• Hackers mess with our applications in unexpected ways. Try to do the same!
• Integrate security into agile dev process (e.g check adherence to secure standards during XP pair programming)
• Validate all input from the user (query strings, form params, action names, ERB output, etc.)
PARTING THOUGHT: STAY PROACTIVE
• Take the laptops if they are left around
• Hack your company yourself
• Match users’ passwords against leaked lists (Sony)
• Be creative
We’re Hiring. Why Work Here?• Well-funded profitable startup
used by millions.• Patented technology utilized in
a new way.• Medical/dental/etc. benefits.• Great office space in mid-town
right near subway.• Flexible hours. Top-notch
compensation + stock options.
Open Positions:•Front-end Engineer •Sys Admin•Tech Lead
•If you are good we’ll find a role for you : [email protected]
Any Questions?....