Talking about Application Security with Dev, QA and Ops. This presentation is based on my own personal experience with developers, deployments and the implementations of such systems. #nightmares

1. Application Security: What do
we need to know?
JOSE L. QUIÑONES, BS
HIT, MCSA, RHCSA, CEH, CPEH, CM2I, GCIH, GPEN

2. About me
UPR School of Medicine – IT Director
Obsidis Consortia, Inc. – Co-Founder & President
Security B Sides Puerto Rico – Head Organizer
InfoSec/Hacker Community – Co-Founder & Mentor
Engine 4 CWS – IoT/Cybersecurity Advisor
Institute of Advance Technology (IAT) – Technical Instructor for
CompTIA, Micro$oft, EC Council and Mile 2

3. Disclaimer
I only do scripting and my point of view is biased toward IT operations.
I am NOT an auditor, nor I care much about compliance for the sake of it.
I am NOT an expert in regulations but like many I have no choice in the matter.
My experience with IT is mainly in the Healthcare, Education and SMB Industries.
This presentation is based on my own personal experience with developers, deployments and
the implementation of such systems. #nightmares
I DO care about information security, privacy and making systems secure.

5. Data Breach Statistics
http://breachlevelindex.com/
2017

6. Today’s price is the Data

7. What’s the surface area of an application?
Client (FrontEnd)
◦ UX/UI
◦ Web, Mobile, OS Binaries
Application/Business Logic
◦ DB Engine
◦ API Calls
◦ Tasks
Data/Infrastructure
◦ Caching
◦ DB
◦ File System

8. What can go wrong?

9. What Are Application Security Risks?
Attackers can potentially use many different paths through your application to do harm to your business
or organization. Each of these paths represents a risk that may, or may not, be serious enough to warrant
attention

10. Application Vulnerabilities
◦Affects home-brew, customized and packaged applications
all the same
◦Usually have vulnerabilities as a result of poor coding, QA ,
deployment and administration
◦All apps are NOT created equal. Each application provides
unique methods of attack it.

11. Common Errors
◦ Bad Coding Practices
◦ Weak authentication and/poor crypto
◦ Bad implementations of security measures
◦ Poor data validation
◦ Written errors or poor error checking
◦ Bad configurations

12. Show me how its done!

13. File Permissions
◦ Many (poorly written)
applications will break
inheritance when saving files
◦ Modify contains every right that
full control does, except for
Change Permission and Take
Ownership.
◦ Giving excessive permissions can
give access to users

14. Network Access
Case: Dr. Alice & Patient Bob
◦ No special hardware was used, only
a stock iPhone
◦ No special tools were used, only
App Store applicacions
◦ Because of bad access
confguration, Bob had access
directly the Alice’s DB files

15. Temp Files
• Temp files from editing,
configuration and
installation tools can
leave interesting
information behind.
• Even if deleted these
file scan be recovered.

16. Config Files

17. Built-in Scripting (Powershell)

18. PII/PHI exposed!

19. Password hashes exposed!

20. GPU cryptanalysis
• Cryptanalysis is used to
breach cryptographic
security systems and gain
access to the contents of
encrypted messages,
even if the cryptographic
key is unknown.

21. What about web/mobile Apps?
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

22. How has application security change?

23. … so, what can we do?

24. Passwords
Do not use personal information for passwords
Do not use dictionary words as passwords
Use at least 3 of the following: a-z, A-Z, 0-9, !@#$%^&*
At least 12-16 characters long
Use passphrases
◦ Ex: 1 Lik3 c0ld Pizz4 W1th Cok@!!
Use a password manager (There are to many passwords)

25. Encryption
At rest
Drive encryption
File encryption
Data encryption
In transit
Encrypted Protocols (SSL/TLS)
End-to-end encryption (IM)
Message encryption (Email)
“I am sure there are better ways to
disguise sensitive information”

26. Backup 3-2-1
* Ransomware will destroy anything on the network

27. User Awareness (Social Engineering)
Common Techniques
◦ Impersonation
◦ Pretext
◦ Framing
◦ Elicitation
Common attacks
◦ Customer Service
◦ Tech support
◦ Delivery person
◦ Phone
◦ Email/Phishing
http://www.social-engineer.org/framework/general-discussion/

28. Ask the right questions …
Are the communications secure?
Are the files saved secure?
What parts of the systems does this application modifies/uses?
What system privileges does the user needs to run the application?
What application privileges does the user have, depending on
his/her role?

29. … getting BAD answers?
Turn off the firewall
We use very strong proprietary encryption
Give Everyone full control permissions
You need Administrator privileges for the application to work.
Create a generic user for everyone

30. Talk to your developers …
◦ Enforce a strong password policy
◦ Use strong encryption with up to date encryption standards
◦ Use strong, salted hashing algorithms
◦ Secure messaging (encrypt & tunnel)
◦ Secure data at rest (whole disk encryption, file encryption and data obfuscation)
◦ Stored procedures and parameterized queries for DB access
◦ Input Validation, Use fuzzers and automatic code review tools.
◦ Use restrictions, triggers and alerts on your DB
◦ Enable audit trails and log everything (success / failure)
◦ Use monitoring tools (Sysmon, Regmon, Windows ADK , ZAP/BurpSuite/Fidler) to
learn how to application works

31. What else?
DevOps!
Integrate IT operations into the
development cycle.

32. THE PHOENIX PROJECT: A NOVEL ABOUT IT,
DEVOPS, AND HELPING YOUR BUSINESS WIN
http://itrevolution.com/books/phoenix-project-devops-book/

33. But, don’t worry …

34. Thanks!
https://codefidelio.org
josequinones@codefidelio.org
@josequinones

35. Security B Sides Puerto Rico
January 27, 2018
Engine-4 CWS & Innovation Center
Bayamon, PR
http://bsidespr.org/2017/
#BsidesPR
@bsidespr