This document provides an overview of security topics that developers need to be aware of, including encryption, authentication, authorization, availability, and other technical security concepts. It discusses security at different levels, from physical security to application security to network security. It also covers security threats, designing security in from the start, balancing convenience and security, and best practices for secure coding and the software development lifecycle. The overall message is that security is holistic and requires consideration across technical, procedural, and human factors.

1. 개발자가 알아야할 보안
조민재
popeye92@gmail.com

3. 보안?
Security?

5. Encryption/Decryption Hash
Availability Confidentiality DoS
Authorization ARP Poisoning Accountability
Authentication SQL Injection
Integrity Non-Repudiation
Defacement
Data leakage Dumpster Diving IP Spoofing
IPS/IDS Infiltration XSS Firewall
Click Fraud Social Engineering
Least Privilege OTP Phishing/Pharming
SSL Virus/Worm Malware
공인인증서

6. Security Is Holistic
Physical Security
Technical Security
Application Security
Operation System Security
Network Security
Policies & Procedures

8. Mitigation of Threats
Authentication Accountability
Authorization Availability
Confidentiality Non-Repudiation
Data / Message Integrity

9. Threats
Defacement Click Fraud
Infiltration Denial-of-Service (DoS)
Phishing Data leakage
Pharming
Insider’s mis-behavior

10. Designing-In Security
Design Features w/ security in mind
Not as an afterthought
Hard to “add-on” security later
Define concrete, measurable security goals
Only certain users should be able to do X.
Output of feature Y should be encrypted.
Feature Z should be available 99.9% of time
Bad Examples : Windows 98, Internet

11. Convenience Vs. Security
Sometimes inversely proportional
More secure -> Less convenient
Too Convenient -> Less secure
Too inconvenient -> unusable
-> users will workaround -> insecure
Good technologies increase both
relative security benefit at only slight inconvenience

12. Security in Software
Requirements
1. Robust, Consistent Error Handling
2.Share requirements w/ QA team
3.Handle internal errors securely
4.Include Validation and Fraud Checks
5.Write Measurable Security Requirements
6.“Security or Bust” policy

13. Security by Obscurity
Hiding how it works + Obfuscation
Reversing/Fuzzing can reveal
Don’t “invent” your own encryption algorithm!
Don’t embed keys/passwd in your software
Don’t put readable value in Windows Registry
Reuse well-tested software

14. Open VS. Close Source
“Is Open-Source Software Secure?”
Open
Some people might look at security of your SW
May or may not tell you what they find
Close
not making code available, but does not hide much
need diverse security-aware code reviews
“The Cathedral and the Bazaar”

15. Secure Coding

16. Secure SDLC

17. Security, however, is an art,
not a science.(RFC3631)

18. Foundation of Security
: What Every Programmer Needs To Know”
By Neil Daswani, Christoph Kern & Anita Kesavan

19. Questions?
whalswo@{ | | }.com
popeye92@{ | }.com
popeye92

20. Thanks