Derbycon 2012 Presentation

1. SIMPLE SECURITY DEFENSE…
TO THWART AN ARMY OF CYBER NINJA
WARRIORS
Ryan Elkins
DerbyCon 2012
Twitter: the_ryan_elkins

2. ABOUT ME
• Information Security Engineer
• Specialized Experience:
• Application Security
• Database Security
• Penetration Testing
• Secure Programming
• Master’s degree in Information Security
• One of the DerbyCon CTF creators
• Twitter: the_ryan_elkins

3. BUT WHY… HOW CAN SECURITY BE SIMPLE?
• Hackers use the same tactics over and over to get in.
• If the same tactics could not be used over and over, there would be no script kiddies
• Probably a lot less information on Pastebin from SQL Injection database dumps
• Automated tools would not be so prevalent
• Hacking methodologies would not be as successful
• www.pentest-standard.org - Excellent resource site for all skills levels.

4. BUILDING AN EFFECTIVE SECURITY PROGRAM
• Let’s deep dive into the necessary components of a successful and effective program.
• Your company’s security posture is like a puzzle…
• All of the pieces have an important part in the big picture.
• All of the pieces need to be in place for a strong security posture.

5. YOU DON’T NEED BOTTOMLESS POCKETS
• Security does not have to be a major cost center for your company.
• Implementing a strong foundation will offer unlimited potential for future investments.
• The good thing is: a security foundation is not expensive!
• But it is necessary.

6. IT IS NOT EXPENSIVE!
• However:
• It requires passionate people.
• It requires planning.
• You cannot buy security.

7. LETS BEGIN BUILDING A PROGRAM

8. BUT WAIT, I HAVE A ZERO DAY…. NOW WHAT!?
• You don’t have to be “one zero-day away from compromise”
• Imagine your CSO or CISO telling the CEO that the company is “one zero-day away
from compromise”
• I would not base my job security on this viewpoint
• There is no comfort in security without layers.

9. LET’S START WITH AN EXPLOIT
• What is a common attack vector that always seems to be vulnerable?

10. LET’S CALL THIS EXPLOIT: CURIOSITY_1337
• Is anyone familiar with Java vulnerabilities or recent Internet Explorer vulnerabilities?
• It makes sense to utilize the Social Engineering attack vector. If you are persistent
enough, it typically has a 100% success rate.

11. TYPICAL SOCIAL ENGINEERING/PHISHING ATTACK
• Let’s attempt to exploit a system with the latest Java vulnerability available in SET.

12. AND HERE IS OUR SHELL

13. ANALYZE THE ATTACK
• What layers did we have to breach for a maximum impact attack:
• User account privileges (local admin, privileged domain account, restrictive account)
• Firewall rules allowing the reverse shell port directly out
• Antivirus detection
• User awareness

14. SECURITY DEFENSES TO IMPLEMENT
• User Awareness Training
• End-Point System Protection
• Network Protection
• Application Security
• Database Security
• Vulnerability Management
• Incident Response
• Governance, Compliance, and Policies

15. USER AWARENESS
• People will always be an inherent risk to the security posture of an organization.
• Most likely the biggest vulnerability.
• The cool thing is, people also have the potential to be the most valuable security asset.
• How great would it be to tell others that your security team is the size of the entire
associate population!

16. MAKE SECURITY THE TREND
• Make it cool.
• Engrain security everywhere.
• Teach your associates to have a security mindset.
• Awareness and training is an invaluable investment.
• Security articles integrated with corporate communications.
• Awareness weeks
• Newsletters
• Posters, bulletins, screen savers

17. GAME TIME

18. WHAT DO YOU SEE?

19. HACKER ANSWER
• I see a way to bypass your company’s physical
security perimeter attack dogs.
• This guy should have had a hot dog with him.

20. PROTECT YOUR USERS
• Ensure standard user accounts are least-privileged.
• Deny local administrative access when possible.
• Create separate administrative level accounts.
• Provide ongoing user awareness throughout the year.

21. END-POINT SYSTEM PROTECTION
• Install antivirus software.
• Sure, a good attacker will test their payload at www.virustotal.com, but this will
combat against known viruses and malicious signatures.
• Apply security patches as soon as they are available.
• Patch management
• Vulnerability mitigation
• Uninstall unused programs
• Ensure that all systems are on the domain.
• Require full disk encryption on user devices.

22. UTILIZE CENTRALIZED MANAGEMENT
• Active directory is a huge asset for security.
• Group policy objects.
• Password Policies
• Enforce security baselines – we will discuss later
• Provision administrative security groups
• Map users to their provisioned file shares so they do not keep all of their company
data on the laptops

23. NETWORK PROTECTION
Don’t Allow This!
• Restrict direct outbound (egress) connections
• Utilize whitelist approach for all direct connections outbound.
• Force web (80, 443) traffic through a proxy server.

24. APPLICATION SECURITY
• Applications are essential to every aspect of the business.
• The doorways and portals to intellectual property, consumer data, financials, access
controls, databases, and your product.

25. HOW WELL DO YOU KNOW YOUR APPS
• Application security is vital for the security posture of your organization.
• Do you have control over the applications being used?
• Do you have an inventory?
• Are you using third-party developed applications?

26. APPLICATION REVIEWS
• Review ALL applications.
• Types of Reviews:
• Source code manual/automated
• Dynamic manual/automated
• Due Diligence
• Train your developers in secure programming practices.

27. SECURE SOFTWARE DEVELOPMENT LIFE CYCLE
• Begin from conception of development idea/planning or 3rd party software procurement
• Continue throughout development cycles
• Perform assessment before application is released
• Perform assessment for major revisions or new releases
• Perform periodic assessments to identify new exposures

28. BUT I DON’T KNOW CODE…
• You don’t have to be a security code ninja to perform an effective application review.
• Obviously:
• the better you are at programming
• the better you are at pentesting
• the better you are at understanding security principles
• the better you are at understanding compliance requirements
• Will make you a better reviewer, but you have to start somewhere…

29. START WITH A CHECKLIST FOR DEVELOPERS
• We provide a checklist to developers that highlight the primary concerns that we have for
every application.
• Developers don’t have time to read and understand every page or article from:
• OSSTM – Open Source Security Testing Methodology Manual
• OWASP – Open Web Application Security Standard
• ASVS – Application Security Verification Standard
• BSIMM – The Building Security in Maturity Model
• PCI – Payment Card Industry
• FIPS – Federal Information Processing Standard
• NIST – National Institute of Standards and Technology
• And there are plenty more

30. APPLICATION RISKS
• Proper protections surrounding every input and output control within an application will
remediate the risk of most vulnerabilities.
• Minimize the surface area for attack

31. LET’S TAKE A LOOK AT THE REVIEW CHECKLIST
• I like to refer to it as a cheat sheet because it makes developers feel like they are able to
pass the reviews by only following these requirements.
• The best part is:
• Proper development surrounding these requirements will remediate nearly all
vulnerabilities.
• Have your security person focused on application security learn and understand the
proper controls surrounding each cheat sheet item.

32. PASSING A SECURITY REVIEW
• The CHEAT SHEET Categories:
• Passwords
• Accounts/Roles
• Cookies
• Databases
• Input Validation
• Output Encoding
• Transport Layer Security
• Web.Config
• Encryption
• Logging and Alerts
• C/C++ Development

33. PASSWORDS
My Online Banking!!!
• 9 character passwords
• Complexity (upper, lower, numbers, special chars)
• Lockout functionality
• Change password functionality
• Logout ability from all sites
• Expiration

34. ACCOUNTS/ROLES
• Generate random password on creation
• Utilize role based security (at least user/administrator levels)

35. COOKIES
• No sensitive data in cookies
• Secure Attribute
• HTTP Only Attribute

36. DATABASES
• Use parameterized or prepared statements for all SQL queries using variable values
• Use least privileged accounts in connection strings (never use SA)
• Use limited accounts for SQL services themselves

37. INPUT VALIDATION
• Validate all external input for length, content, and type using regular expressions
• Don’t use conversions to validate input
• Use whitelist approach– no blacklists
• Server side validation only – Client side can be bypassed

38. OUTPUT ENCODING
• Use HTML encoding for any untrusted data that is displayed in literal controls (labels,
tables) on a page
• Use URL encoding for any untrusted parameters in a URL

39. TRANSPORT LAYER SECURITY
• SSL for Logins/Sensitive information
• Disable insecure ciphers
• No certificate mismatches, untrusted CA’s, revoked certs, or self-signed certs
• Disable deprecated/insecure protocol versions

40. WEB.CONFIG
• Encrypt any sensitive sections of the config files (connection strings, keys, passwords)
• Configure customErrors
• Compilation debug is turned off
• ValidateRequest is on
• Encrypt Viewstate

41. I’ve found these hard-coded
values from Obviex used so
CRYPTOGRAPHIC STORAGE many times!!!
• No hard-coded encryption keys
• Use secure hashing algorithms like SHA-256 or SHA-512
• Generate a unique salt when hashing a password
• You salt your potatoes, you salt your french fries, you salt your hash.
• Use strong encryption algorithms like AES-256

42. LOGGING AND ALERTS
• Log all security type events (login, logout, add/remove users, uploads, errors)
• No sensitive info in logs
• Provide generic error messages to users and log the details

43. C/C++ DEVELOPMENT
• Utilize the secure alternatives for functions when available (include banned.h)
• Validate all buffers before adding data

44. 3RD PARTY APPLICATIONS

45. WHAT TO DO ABOUT 3RD PARTY APPLICATIONS
• You will not always have 3 rd party code to review.
• I always ask for the code and say that we require a code review before it can be used in
the organization.
• Under NDA, they often are willing to provide the code.
• Worst case: they say no
• Makes sense because it is usually a full ASVS review of their application for free.
• Could count as an audit checkmark for a third party code review.

46. 3RD PARTY REVIEW WITHOUT CODE
• Very hesitant to allow third party applications on external perimeter without full code
review.
• Utilize tools like:
• .NET Reflector to open binaries if .Net applications
• JD-GUI for opening Java binaries
• IDA-Pro to search strings
• Look closely at authentication mechanisms for hard-coded values and backdoors
• Search for hard-coded cryptographic information (encryption keys, IVs, Salt values)
• Perform a due-diligence review of the vendor.
• Questionnaire regarding security programming process, developer training
• Internet research regarding the company (past vulnerabilities, breaches)

47. APPLICATION REVIEW RESULTS
• Since the application program has been deployed globally
• Findings in internally developed applications have decreased tremendously
• Developers are eager to learn and implement security
• The key is teaching, sharing, and patience. They are not reading about security
24/7 like us.
• Internally developed applications have a much stronger security posture than 3 rd
party developed applications
• Require source code reviews for all externally facing applications.

48. DATABASE SECURITY
• Leverage your application security program as a window into your databases.
• The majority of databases that I have seen have an application communicating with it.

49. QUICK DATABASE SECURITY WINS
• Utilize integrated authentication and disable local database accounts when applicable.
• This centralizes account and password policies to Active Directory
• Ensure that application connection strings utilize least privileges (never SA)
• Keep database servers separate from web and application servers
• Utilize network segmentation and DMZs for externally facing or DBs with
sensitve/confidential information
• Separation of duties between administrators and developers.

50. VULNERABILITY MANAGEMENT
• Patching processes (operating systems, applications, hardware)
• Timelines for applying updates based on criticality
• Maintain a list of approved and supported applications
• Restrict users from installing applications
• Scheduled vulnerability scans and device discovery
• Integrate application and database review findings into tracking/remediation processes

51. DATA LOSS PREVENTION – CLOUD STORAGE
• Do you know how much of your data is going to the cloud?
• Are your users backing up their computers to the cloud?
• Provide corporate shares for your users to minimize business information on personal
devices.

52. CENTRALIZATION IS KEY TO EFFECTIVENESS
• Centralize the management of everything you can
• Standard computer and server images
• Connect everything to the domain for Group Policy management
• Know and understand the architecture of every application
• Ensure that all network segments are included in vulnerability scans
• Maintain a list of all external websites
• Track and remediate all vulnerabilities discovered

53. SO WHERE DO I BEGIN?
• If you implement everything so far, your program will not be successful without several
core components:
• Policies
• Baselines
• Risk Acceptance Model
• Yes, these are the most boring components, but are absolutely vital for building a
successful program.

54. POLICIES
• Without a policy, enforcement and accountability cannot occur
• These are the laws of the organization
• If they did not exist, associates could not be charged for
breaking them
• Types of policies/categories:
• Acceptable Use
• Data Classification
• Application Security
• Network Security
• Database Security
• Some of these could be wrapped in an Information Security Policy

55. BASELINES
• These are the technical details
• Baselines should be created for all supported technologies:
• Operating Systems
• Databases
• Network Devices
• Applications

56. RISK ACCEPTANCE
• The security team will not always be willing to sign-off on everything.
• At times, you have to advise, identify risks, and the business may decide it is worth the
risk.
• Utilize a risk acceptance model where an executive or business manager must sign-off
and accept the risks identified by the security team.
• The risk acceptance documents can then be reviewed periodically by internal audit teams
• Require a remediation plan and timeline to mitigate accepted risks

57. TIME TO BUILD
• Once you have these foundational security defenses in place, you are ready to begin
investing in additional security technologies to advance your security posture.
• How many of you already have all of this in place?
• It is a daily process as the organizations changes (technology, processes, associates)
Don’t let your security
program look like this!

58. CLOSING THOUGHTS
• You have to be passionate about what you do to be successful.
• Be the positive change the world needs.
• Bring out the best in others.
• Use the hard times to grow and become a better person. You may be able to use your
experiences to help others through their hardships.
• All of these are vital for being happy in your career, even when you are doing something
you love.
• Never stop learning.

59. FIND TIME TO ENJOY THE BEAUTY OF LIFE