This document summarizes strategies for building secure systems. It discusses making security a core requirement from the beginning, employing secure software architecture and development practices, isolating processes using sandboxes, avoiding cleartext data, using libraries carefully and keeping them updated, auditing code, and continuously improving security. The overall message is that security must be prioritized throughout the entire system development lifecycle in order to successfully build resilient systems.

1. 1
BUILDINGSECURE
SYSTEMSHowtobuildsystems
thatresistattacks
CYBERSECURITY
WEBINARPART6
JARNONIEMELÄ
F-SECURE
3th ofDecember2015

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
BUILDING
SECURE
SYSTEMS
JARNONIEMELÄ
SENIORRESEARCHER
F-SECURE

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. THANK YOUFORYOUR
PARTICIPATION!
17
The Recording will be available at the BUSINESS SECURITY INSIDER
https://business.f-secure.com/https://business.f-
secure.com