개발자가 알아야 할 보안
Upcoming SlideShare
Loading in...5
×
 

개발자가 알아야 할 보안

on

  • 672 views

OSS 3차 멘토링

OSS 3차 멘토링

Statistics

Views

Total Views
672
Views on SlideShare
672
Embed Views
0

Actions

Likes
2
Downloads
20
Comments
1

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • 정약용도 그러고 굴원도 그러고 ...
    아무튼 생각할 시간을 갖는다는 것은 그리 나쁜 것은 아닌 것 같다.
    간결하고 절제된 좋은 PPT가 나오잖아!
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • 이상으로 저희가 준비한 세 가지 제안을 말씀드렸습니다. 그런데, 한 가지 더 있습니다. \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 이상으로 저희가 준비한 세 가지 제안을 말씀드렸습니다. 그런데, 한 가지 더 있습니다. \n

개발자가 알아야 할 보안 개발자가 알아야 할 보안 Presentation Transcript

  • 개발자가 알아야할 보안 조민재 popeye92@gmail.com
  • 보안?Security?
  • Encryption/Decryption Hash Availability Confidentiality DoS Authorization ARP Poisoning Accountability Authentication SQL Injection Integrity Non-Repudiation DefacementData leakage Dumpster Diving IP Spoofing IPS/IDS Infiltration XSS Firewall Click Fraud Social Engineering Least Privilege OTP Phishing/Pharming SSL Virus/Worm Malware 공인인증서
  • Security Is HolisticPhysical SecurityTechnical Security Application Security Operation System Security Network SecurityPolicies & Procedures
  • Mitigation of ThreatsAuthentication AccountabilityAuthorization AvailabilityConfidentiality Non-RepudiationData / Message Integrity
  • ThreatsDefacement Click FraudInfiltration Denial-of-Service (DoS)Phishing Data leakagePharmingInsider’s mis-behavior
  • Designing-In SecurityDesign Features w/ security in mind Not as an afterthought Hard to “add-on” security laterDefine 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 timeBad Examples : Windows 98, Internet
  • Convenience Vs. SecuritySometimes inversely proportional More secure -> Less convenient Too Convenient -> Less secureToo inconvenient -> unusable-> users will workaround -> insecureGood technologies increase both relative security benefit at only slight inconvenience
  • Security in Software Requirements1. Robust, Consistent Error Handling2.Share requirements w/ QA team3.Handle internal errors securely4.Include Validation and Fraud Checks5.Write Measurable Security Requirements6.“Security or Bust” policy
  • Security by ObscurityHiding how it works + ObfuscationReversing/Fuzzing can revealDon’t “invent” your own encryption algorithm!Don’t embed keys/passwd in your softwareDon’t put readable value in Windows RegistryReuse well-tested software
  • 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 findClose not making code available, but does not hide much need diverse security-aware code reviews “The Cathedral and the Bazaar”
  • Secure Coding
  • Secure SDLC
  • Security, however, is an art, not a science.(RFC3631)
  • Foundation of Security: What Every Programmer Needs To Know”By Neil Daswani, Christoph Kern & Anita Kesavan
  • Questions?whalswo@{ | | }.com popeye92@{ | }.com popeye92
  • Thanks