Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1
BUILDINGSECURE
SYSTEMSHowtobuildsystems
thatresistattacks
CYBERSECURITY
WEBINARPART6
JARNONIEMELÄ
F-SECURE
3th ofDecembe...
CYBERSECURITY WEBINAR
SERIES-PART6
© F-Secure2
• INTRODUCTION TO CYBERSECURITY
• DEFENDING WORKSTATIONS
• DEFENDING SERVER...
3
BUILDING
SECURE
SYSTEMS
JARNONIEMELÄ
SENIORRESEARCHER
F-SECURE
There AreNoPerfect
Systems
It is impossible to build a system that would not have any flaws
But you can build systems that...
Security asaCore
requirement
You get what you ask for, and have in contract
 No matter whether it is internal development...
Security AndSoftware
Architecture
There are many similarities between software and building architecture
 Fixing security...
Security Standards
One way to get security in software is to follow some security standards
 ISO27k standards http://www....
Use SafeProgramming
Favor safe languages for the task at hand
 C# over C++, Java over Python, Python over PHP or Perl
 H...
TreatIncomingDataWith
Caution
Most vulnerabilities are essentially data input problems
 Attacker was able to feed data th...
MakeSure ThatSecurity Is
Tested
Testing very easily focuses only on verifying that a program works correctly
 Security te...
Sandbox EveryProcess
It is very likely that an attacker will find an exploitable vulnerability
 But that does not need to...
AvoidProcessing ClearText
Store only data that you need
 In recent data leaks there has been a ton of data that should ha...
Use Libraries Where Possible
The less your team has to code the less there is to fix
 Use public libraries when there are...
SignYour Code
Use digital signatures for every binary, and verify signatures
 Update tampering attacks are trivial if upd...
AuditYour Code
Perform internal or external audits on your code
 Audit does not guarantee quality, but it helps to mainta...
Conclusions
Security is not about following some standard
 Although standards do help a lot
Security is about doing thing...
THANK YOUFORYOUR
PARTICIPATION!
17
The Recording will be available at the BUSINESS SECURITY INSIDER
https://business.f-sec...
Upcoming SlideShare
Loading in …5
×

Cyber security webinar 6 - How to build systems that resist attacks?

295 views

Published on

Building secure software starts from the very beginning of the development process. Trying to fix security at the end of the development cycle is much harder. And even if it is impossible to build systems that would be totally secure from every breach attempt and that have no flaws, you can build systems that cyber attackers will find extremely hard to breach. Find out more how to build secure systems from the webinar recording in the following link and the presentation slides.
https://business.f-secure.com/how-to-build-systems-that-resist-attacks/

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Cyber security webinar 6 - How to build systems that resist attacks?

  1. 1. 1 BUILDINGSECURE SYSTEMSHowtobuildsystems thatresistattacks CYBERSECURITY WEBINARPART6 JARNONIEMELÄ F-SECURE 3th ofDecember2015
  2. 2. CYBERSECURITY WEBINAR SERIES-PART6 © F-Secure2 • INTRODUCTION TO CYBERSECURITY • DEFENDING WORKSTATIONS • DEFENDING SERVERS • DEFENDING NETWORKS • RESPONDING TO AN INCIDENT • BUILDING SECURE SYSTEMS NOW RECORDINGS: HTTPS://BUSINESS.F-SECURE.COM
  3. 3. 3 BUILDING SECURE SYSTEMS JARNONIEMELÄ SENIORRESEARCHER F-SECURE
  4. 4. There AreNoPerfect Systems It is impossible to build a system that would not have any flaws But you can build systems that are very difficult to break  Security as a Core requirement  Security and software architecture  Use safe programming practices and OS capabilities  Make sure also security is tested  Isolate each process using sandboxes or other virtualization  Avoid processing clear text data  Use ready code, but keep track of the security status of all third party libraries you use  Audit your code either internally or use a consultant © F-Secure4
  5. 5. Security asaCore requirement You get what you ask for, and have in contract  No matter whether it is internal development or contractor  This means that security has to be in RFPs and system requirements  Otherwise development will self optimize, which is to do as little as possible Security goals and targets have to be a part of the process  Have security as part of your request for proposals when ordering software  And have it in the requirements documentation when developing in-house  Microsoft Software Development Life Cycle https://www.microsoft.com/en-us/sdl/ The earlier you plan security in, the cheaper it will be in the long run © F-Secure5
  6. 6. Security AndSoftware Architecture There are many similarities between software and building architecture  Fixing security problems when software is in production is 60 times more expensive than preventing it at design stage  Soo Hoo K, Sudbury AW, & Jaquith AR, Secure Business Quarterly, 5 pp, Q2 2001 Modularization is the core of good and secure architecture  Isolate functions into their own modules  Make sure each module has only the access that it needs Do security and threat modeling  Think how your system can be attacked, and how you could mitigate those vectors © F-Secure6
  7. 7. Security Standards One way to get security in software is to follow some security standards  ISO27k standards http://www.iso27001security.com/  PCI-DSS https://www.pcisecuritystandards.org/security_standards/  Common Criteria https://www.commoncriteriaportal.org/cc/ However merely following a standard does not guarantee security  Standards are at the same time very extensive, and too high level  This means that following f.ex ISO standards is useful, and some customers require it  Especially large contracts require an audit that a standard is followed  But no standard can really ensure implementation quality © F-Secure7
  8. 8. Use SafeProgramming Favor safe languages for the task at hand  C# over C++, Java over Python, Python over PHP or Perl  Haskell and Rust have better built in safety, but it’s difficult to find programmers Make sure programmers have safe programming training Follow security best practices for the language your company uses  https://www.owasp.org/  https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards Enable every security option provided by the OS and compiler  DEP, ASLR, GS, SafeSEH, etc https://msdn.microsoft.com/en-us/library/k3a3hzw7.aspx © F-Secure8
  9. 9. TreatIncomingDataWith Caution Most vulnerabilities are essentially data input problems  Attacker was able to feed data that the programmer was not expecting Thus all incoming data needs to be treated with caution  Any code reading and handling data needs to be carefully reviewed  Filter out any data that you do not need Example: Barcode readers are basically USB keyboards that read barcode  The input is read and transmitted as keypresses over USB  Unless the receiver program filters input, the attacker can execute code with barcode © F-Secure9 http://www.slideshare.net/PacSecJP/ hyperchem-ma-badbarcode- en1109nocommentfinal
  10. 10. MakeSure ThatSecurity Is Tested Testing very easily focuses only on verifying that a program works correctly  Security testing tries to break software in ways never seen in real use Use static and runtime code analysis tools to find out potential vulnerabilities  https://www.owasp.org/index.php/Static_Code_Analysis Use fuzzing analysis to find crashes and vulnerabilities  https://www.owasp.org/index.php/Fuzzing  http://lcamtuf.coredump.cx/afl/ Read hacking books for your environment, and try the methods on your software © F-Secure10
  11. 11. Sandbox EveryProcess It is very likely that an attacker will find an exploitable vulnerability  But that does not need to be the end of the world Use sandboxing or app virtualization techniques to isolate every component  For Linux use AppArmor, Grsecurity, TOMOYO  For Windows use access control to run process with minimum privileges https://msdn.microsoft.com/en-us/library/windows/desktop/aa374860(v=vs.85).aspx  Or use Chromium sandbox https://www.chromium.org/developers/design-documents/sandbox/  Windows Server 2016 container model also looks very promising Once code runs in a sandbox you can control access to every resource  Allow only what the code needs, deny everything else © F-Secure11
  12. 12. AvoidProcessing ClearText Store only data that you need  In recent data leaks there has been a ton of data that should have been deleted Hash information where the original data is not needed  Hash both user name and password, have cleartext username in memory not in DB  Use slow key derivation functions (PBKDF2, Scrypt, Bcrypt) with >1M iterations Do not communicate cleartext data to frontend  In most of cases it’s the frontend that gets compromised  Isolate data behind API, encrypt data coming to frontend with users password  Thus if attacker is able to compromise frontend, he cannot use the data without PW © F-Secure12
  13. 13. Use Libraries Where Possible The less your team has to code the less there is to fix  Use public libraries when there are good options available  Especially avoid writing own crypto (unless you have real experts, that is) However be aware of the security history of the code you use  How many known vulnerabilities there have been in the past?  What is the impression they give of code quality, were they beginner mistakes?  How quick was the patch provided after a vulnerability was found Know where to get updates and take them into use as soon as possible © F-Secure13
  14. 14. SignYour Code Use digital signatures for every binary, and verify signatures  Update tampering attacks are trivial if updates are not verified  Thus you need to verify that code is signed, and pin to CA certificate  Digital signature verification protects also against viruses, tampering and cracking  But do make sure that you store code signing cert securely Digital signatures help to avoid AV false alarms  Some vendors trust signatures blindly, which is not good but useful for SW dev  Others use signatures to build reputation, and trust well known signatures © F-Secure14
  15. 15. AuditYour Code Perform internal or external audits on your code  Audit does not guarantee quality, but it helps to maintain it  Make sure that audit discoveries lead to improvements But an audit at end of the project is a very expensive way to get quality  Focus on programmer education and constant improvement  Whenever there is a problem, do root cause analysis and learn from it  Encourage environment that promotes professional engineering © F-Secure15
  16. 16. Conclusions Security is not about following some standard  Although standards do help a lot Security is about doing things right  Make sure security is a part of requirements  Make sure security is a core requirement in architecture  Make sure software production is done with security in mind  Isolate every component as well as possible  Test your software, not only that it works, but try to attack it  Be reachable when someone wants to report a security bug © F-Secure16
  17. 17. THANK YOUFORYOUR PARTICIPATION! 17 The Recording will be available at the BUSINESS SECURITY INSIDER https://business.f-secure.com/https://business.f- secure.com

×