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.
1. What CTOs Need to Know About Security
Aleksandr Yampolskiy
2. 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: alexyampolskiy@blogtalkradio.com
Twitter: @ayampolskiy
Blog: http://www.ctothoughts.com
12. 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”. Love And Other Drugs
• Build security into the
software development
lifecycle.
13. RULE #1 : GET THE EXECUTIVE BUY-
IN
Security
projects
Business
projects
“IT security needs a philosophy and only a CEO can make that kind of a
decision.” -Hyundai Capital CEO Ted Chung
14. 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.
15. 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.
16. 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.
17. Hackers are Well Aware of That Fact
THC HYDRA
CUPP
Default password
lists
18. CREATE A STRONG PASSWORD
Protect your data and system access from guessing and attacks!
KEYS TO A STRONG PASSWORD
LENGTH
At least 7 characters in length
COMPLEXITY
• Uppercase letters
• Lowercase letters
• Numbers
• Symbols
RANDOMNESS
• Use a song title,
affirmation, popular phrase, EXAMPLE
or interest I CAN EAT CANDY EVERY SINGLE
• Mix in other characters to DAY = iCEc@24x7!
add complexity
19. 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!)
20. 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
22. 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)
23. Hamster Wheel of Pain
• Developers write code, we find security bugs, prioritize
them with PMs, fix them. Lather, rinse, repeat.
24. 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.
25. 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)
SLA for Security Jira Tickets
Priority: Blocker
2
1.8
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0
0-10 11-30 31-60 60+
26. 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+”)) { … }
27. 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
28. 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
29. 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.
30. Example web environment
Securing the application
InternetInput validation DMZ
Session mgmt Protected
Authentication Internal
Authorization Config mgmt network
Error handling network
Secure storage Auditing/logging
DB
Web app
Web app
App
transport Web server Web app
server (optional) Web app
DB
Securing the network Securing the host
Router Patches/updates Accounts Ports
Firewall Services Files/directories Registry
Switch Protocols Shares Auditing/logging
32. 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 Some weak passwords here and Few weak passwords or 2-
default ones there 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 All servers and workstations
are hardened are hardened
33. 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.
34. 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.)
35. 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
36. Parting Thought
Often the easiest way to break security
is to circumvent it rather than defeat it.
36
37. We’re Hiring. Why Work Here?
• Well-funded profitable startup Open Positions:
used by millions. •Front-end Engineer
• Patented technology utilized in •Sys Admin
a new way.
•Tech Lead
• Medical/dental/etc. benefits.
• Great office space in mid-town
right near subway. •If you are good we’ll find a
• Flexible hours. Top-notch role for you :
compensation + stock options. jobs@ cinchcast.com