소프트웨어보안(Software Security)

조성제 (Cho, Seong-je)

Fall, 2019

Computer Security & OS Lab.

Dankook University

CS412 Software Security

Mathias Payer -- Spring semester 2019

https://nebelwelt.net/teaching/19-412-SoSe/

Computer Security & OS Lab, DKU 2

Many slides taken from Prof. Mathias Payer’s Lecture

Software Security: Principles, Policies, and Protection (SS3P)

A Free Book : https://nebelwelt.net/SS3P/softsec.pdf

CS412 Software Security• https://nebelwelt.net/teaching/19-412-SoSe/

Course overviewThis course focuses on software security fundamentals, secure coding guidelines and principles, and advanced software security concepts. Students will learn to assess and understand threats, learn how to design and implement secure software systems, and get hands-on experience with common security pitfalls.

Course objectiveSoftware running on current systems is exploited by attackers despite many deployed defence mechanisms and best practices for developing new software. In this course students will learn about current security threats, attack vectors, and defence mechanisms on current systems. The students will work with real world problems and technical challenges of security mechanisms (both in the design and implementation of programming languages, compilers, and runtime systems).

Computer Security & OS Lab, DKU 3

CS412 Software Security (Prof. Mathias Payer)

Learning outcomesStudents who complete the course will have demonstrated the ability to do the following:

● Explain the top 20 most common weaknesses in software security (CWE top 20) and understand how such problems can be avoided in software.

● Identify common security threats, risks, and attack vectors for software systems.

● Evaluate and assess current security best practices and defense mechanisms for current software systems. Become aware of limitations of existing defense mechanisms and how to avoid them.

● Identify security problems in source code and binaries, assess the associated risks, and reason about their severity and exploitability.

● Assess the security of given source code or applications.

4Computer Security & OS Lab, DKU

CS412 Software Security (Prof. Mathias Payer)

Schedule

● Course introduction (2019/09/??)

● Basic principles (2019/09/ )

● Secure software lifecycle (2019/09/ ) [1]

● Reverse engineering (2019/09/ )

● Security policies (2019/10/ ) [2], [3], [4] [5] [6]

● Software bugs (2019/10/ )

● Attack vectors (2019/10/ )

● Mitigations (2019/10/ )

● Advanced mitigations (2019/11/ ) [9], [10] [13] [14]

● Testing: Sanitization (2019/11/ ) [11]

● Testing: Fuzzing (2019/11/ )

● Web security (2019/11/ )

● Mobile security (2019/12/ )

● Summary (2019/12/ )

5Computer Security & OS Lab, DKU

Software and Software Security

Vulnerability

Computer Security & OS Lab, DKU 6

Quiz

What do wireless devices, cell phones, PDAs, browsers, operating systems, servers, personal computers, public key infrastructure systems, and firewalls have in common?

7Computer Security & OS Lab, DKU

8Computer Security & OS Lab, DKU

9

Software is ubiquitous

The information age, in fact, is an extension of the industrial age, characterized by the focus on production of physical goods.

● Ubiquitous software is a characteristic of the information age.

Software is essential to the operation of the Nation’s critical infrastructure.

● The nation's critical infrastructure (energy, transportation, telecommunications, etc.), businesses, and services are extensively and increasingly controlled and enabled by software.

Software is used today for communications, production, financial transactions, transportation, and utilities to name just a few of its varied and countless uses

● Government, education, healthcare, banking, retail, wholesale, insurance, and media sectors

10Computer Security & OS Lab, DKU

SW is everywhere

11Computer Security & OS Lab, DKU

Software

Software is everywhere● A modern product delivery’ survey found that 23% of products now contain software in

some form

● In 2001, cars had a minimal amount of code in them. A new car now has about 100 million lines of code. What’s more, it is expected that more than 150 million connected cars will be on America’s highways and byways by 2020

With software, technical solutions to business problems are possible

FinTech, AI, Big data, Cloud, Blockchain, …

With software, we can all be connected.

12Computer Security & OS Lab, DKU

Software

It isn’t just applications. It’s also

● operating systems

● frameworks

● middleware

● security systems

● communications/networking systems

● embedded systems

● firmware (shares with software: executable, readable, writeable, and at risk).

Software monitors and controls life-critical physical systems.

Software manipulates, protects, and exposes extremely sensitive information.

Software is itself protected by other software.

The vast majority of software is not “built from scratch”.

13Computer Security & OS Lab, DKU

Software is imperfect.

Software is imperfect, just like the people who make it● No matter how much work goes into a new version of software, it will

still be fallible.

The Reasons Why Software Is Vulnerable● Software is vulnerable due to complexity and inevitable human error.

● Many vendors (e.g., Microsoft, Sun, Oracle, and others) that developed and built their software in the 90's didn't write code that was secure from heap overflows or format string bugs, because these issues were not widely known at the time.

Outdated software is the root of evil

14Computer Security & OS Lab, DKU

Why YOUR software is a valuable target:

Because it’s flawed.

Because software vendors can hardly keep up with the way cyber criminals exploit vulnerabilities in their products.

● Vulnerability

− A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy

− a mistake in software that can be directly used by a hacker to gain access to a system or network

Because it’s used by millions.

Because it gives them access to your computer in minutes.

Because you’re sometimes careless when using the Internet. (We’ve all been there, trust me.)

Source: https://heimdalsecurity.com/blog/vulnerable-software-infographic/

15Computer Security & OS Lab, DKU

Software vs. Vulnerability

Vulnerabilities in software can jeopardize intellectual property, consumer trust, and business operations and services

● Vulnerability is a mistake in software that can be directly used by a hacker to gain access to a system or network

Vulnerabilities in that software put those resources at risk.

● The risk is compounded by software size and complexity, the use of software produced by unvetted suppliers, and the interdependence of software systems.

16Computer Security & OS Lab, DKU

Compound: 악화시키다, 더 심각하게 만들다. ~으로 구성되다.vet : (내용품질 등을) 점검하다. (어떤 직책을 맡게 될 사람에 대해) 심사하다.unvetted : (내용품질 등을) 검열 받지 않은, 점검 받지 않은

The most vulnerable players of 2017

https://techtalk.gfi.com/the-most-vulnerable-players-of-2017/

CVE: Common Vulnerabilities & Exposures (source: https://cve.mitre.org/)

● In 2016, 6,447 vulnerabilities were reported. In 2017, that number increased to 14,709

17Computer Security & OS Lab, DKU

The most vulnerable players of 2017

The top kinds of vulnerabilities include DoS meaning the vulnerability would allow hackers to not allow users from logging in or their computers not to work, and code execution where codes can be manipulated easily.

18Computer Security & OS Lab, DKU

The most vulnerable players of 2017

Vendors

● Though Google had significantly more vulnerabilities than Oracle, the numbers below also include mobile devices. With the number of products Google has, it must be a real challenge for them to keep up with vulnerabilities. They top out the list of having 1000 reported CVEs in 2017 with Oracle not too far behind.

19Computer Security & OS Lab, DKU

The most vulnerable players of 2017

Operating system

● The increase in vulnerabilities in mobile devices has gone up over the years, and we do not believe the trend is going to subside anytime soon.

20Computer Security & OS Lab, DKU

The most vulnerable players of 2017

Browsers

● All someone has to do is click a link that downloads malicious software, and your network is compromised.

● Though Edge had 202 vulnerabilities in 2017, it only had 3.78% of the market share according to the NetMarketShare.

21Computer Security & OS Lab, DKU

● Chrome is currently the most used browser and has experienced a substantial increase in market share from 2015 by climbing from 27.61% to 58.9% in 2017.

The most vulnerable players of 2017

Mobile devices

The popularity trend of more market share = more vulnerabilities can be seen once more and with Android having around 80% market share in smartphone OS

22Computer Security & OS Lab, DKU

ApplicationsApplications were also in need of patching last year especially ImageMagick which comes in as number one. The application allowed Yahoo private mail users to view images. Unfortunately, the vulnerability was discovered by hackers, causing the “YahooBleed Bug” to emerge. To save face, Yahoo retired the ImageMagick library altogether.

2015’s MVPs – The most vulnerable players

Mobile devices● not sure if Windows

Phone doesn’t show up because it’s so secure, or because it’s such a tiny slice of the market

Applications

23Computer Security & OS Lab, DKU

The most vulnerable players of 2017

We should also note that there is a very low number of vulnerabilities in Adobe Flash which we have not experienced in recent years. ● However, other Adobe applications topped the list right after ImageMagick.

● There are reports that Adobe Flash will phase out by 2020 which could indicate little development on the application.

Being informed of the kinds of vulnerabilities that keep your network open to potential threats is only one part of the game.● No network is safe.

The number of vulnerabilities continues to go up every year and keeping up with patches is daunting.

daunting: 벅찬, 주눅이들게하는 (daunt: 겁먹게[기죽게]하다.)

24Computer Security & OS Lab, DKU

CVE (Common Vulnerabilities & Exposures)

a vulnerability is a state in a computing system (or set of systems) that either:

● allows an attacker to execute commands as another user

● allows an attacker to access data that is contrary to the specified access restrictions for that data

● allows an attacker to pose as another entity

● allows an attacker to conduct a DoS

Examples of vulnerabilities include:

● phf (remote command execution as user "nobody")

● rpc.ttdbserverd (remote command execution as root)

● world-writeable password file (modification of system-critical data)

● default password (remote command execution or other access)

● DoS problems that allow an attacker to cause a Blue Screen of Death

● smurf (denial of service by flooding a network)

25Computer Security & OS Lab, DKU

Gateways to Infection: Exploiting SW Vulnerabilities

Source: TREND Micro

(http://about-threats.trendmicro.com/RelatedThreats.aspx?language=tw&name=Gateways+to+Infection%3A+Exploiting+Software+Vulnerabilities)

26Computer Security & OS Lab, DKU

What is a software vulnerability?

A software vulnerability is a security flaw, glitch, or weakness found in software or in an OS that can lead to security concerns.

● An example of a software flaw is a buffer overflow This is when software becomes unresponsive or crashes when users open a file that may be "too heavy" for the program to read.

This commonly encountered error becomes a security concern when attackers uncover the vulnerability, conduct research about it, and create a malicious code or exploit that targets this glitch to launch their schemes.

● Some schemes may include gaining administrator privileges which gives attackers control over the vulnerable system or infecting it with malware.

Vulnerabilities are found in all software and OSs and are not limited to a particular software vendor.

● For 1Q 2012, Apple posted the highest number of reported vulnerabilities and also issued their largest number of patches during the same time period.

Users tend to not notice software vulnerabilities.

● An attacker may target one without the software showing any sign of an attack.

Attackers can also target vulnerabilities without user having to visit a malicious site or download an exploit such as attacks that target CVE-2012-2526 and CVE-2012-1852.

27Computer Security & OS Lab, DKU

What is an exploit?

An exploit is a code purposely created by attackers to abuse or target a software vulnerability. [from TREND Micro]

● This code is typically incorporated into malware.

● Once the exploit code is successfully executed, the malware drops a copy of itself into the vulnerable system.

In some cases, an exploit can be used as part of a multi-component attack.

● Instead using a malicious file, the exploit may instead drop another malware, which can include backdoor Trojans and spyware that can steal user information from the infected systems.

28Computer Security & OS Lab, DKU

What is an exploit?

An exploit (from the English verb to exploit, meaning "using something to one’s own

advantage") is a piece of software, a chunk of data, or a sequence of commands that takes advantage of a bug, glitch or vulnerability [from wikipedia]

● There are several methods of classifying exploits The most common is by how the exploit contacts the vulnerable software.

● A remote exploit works over a network and exploits the security vulnerability without any prior access to the vulnerable system.

● A local exploit requires prior access to the vulnerable system and usually increases the privileges of the person running the exploit past those granted by the system administrator.

29Computer Security & OS Lab, DKU

Security Vulnerability [from webopedia]

An unintended flaw in software code or a system that leaves it open to the

potential for exploitation in the form of unauthorized access or malicious

behavior such as viruses, worms, Trojan horses and other forms of malware.

Security vulnerabilities can result from software bugs, weak passwords or software that’s already been infected by a computer virus or script code injection, and

● these security vulnerabilities require patches, or fixes, in order to prevent the potential for compromised integrity by hackers or malware.

30Computer Security & OS Lab, DKU

Software Vulnerabilities

Memory safety violations, such as:

● Buffer overflows and over-reads

● Dangling pointers

Input validation errors, such as:

● Format string attacks

● SQL injection

● Code injection

● E-mail injection

● Directory traversal

● Cross-site scripting in web applications

● HTTP header injection

● HTTP response splitting

31Computer Security & OS Lab, DKU

Race conditions, such as:

● Time-of-check-to-time-of-use bugs

● Symlink races

Privilege-confusion bugs, such as:

● Cross-site request forgery in web applications

● Clickjacking

● FTP bounce attack

Privilege escalation

User interface failures, such as:

● Warning fatigue[31] or user conditioning.

● Blaming the Victim Prompting a user to make a security decision without giving the user enough information to answer it[32]

● Race Conditions[33][34]

Vulnerability

a weakness which allows an attacker to reduce a system's information assurance● a mistake in software that can be directly used by a hacker to gain access to a system or

network

A weakness of an asset or group of assets that can be exploited by one or more threats. (by ISO 27005)

A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy. (by IETF RFC 2828)

A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy. (by NIST)

The existence of a weakness, design, or implementation error that can lead to an unexpected, undesirable event [G.11] compromising the security of the computer system, network, application, or protocol involved.(ITSEC) (by ENISA)

32Computer Security & OS Lab, DKU

Software Security

Security in the Software Life Cycle, OMG SwA Workshop,

Karen Mercedes Goertzel, Mar. 2007.

Computer Security & OS Lab, DKU 33

Source and References

Security in the Software Life Cycle, OMG SwA Workshop, Karen Mercedes Goertzel, Mar. 2007. Booz | Allen | Hamilton● https://pdfs.semanticscholar.org/d491/4522884d709aa142012a2a91e1e0b821342c.pdf

● Security Challenges for Systems Built from Nondevelopmental Software Components—Brown Bag 02.22.07

K.M. Goertzel, et al: Security in the Software Life Cycle Draft Version 1.2 (DHS NCSD Software Assurance Program, Sept. 2006) – new version planned in 2007

Software Security Assurance, State-of-the-Art Report (SOAR), July 31, 2007.

US-CERT BuildSecurityIn portal -- https://buildsecurityin.us-cert.gov/

Security in the Software Development Lifecycle, Hala Assal and Sonia Chiasson, Carleton University, Aug. 2018.● https://www.usenix.org/conference/soups2018/presentation/assal

Enhancing the Development Life Cycle To Produce Secure Software, Karen Mercedes Goertzel, Booz | Allen | Hamilton

34Computer Security & OS Lab, DKU

Threats to software

External

● Human attackers

● Malicious processes

Inside

● Rogue developers

● Rogue administrators

● Rogue users

Embedded

● Malicious logic

● Intentional vulnerabilities

● Backdoors

rogue: 독자적으로행동하는 (흔히해를끼치기도하는), 사기꾼/불한당

35Computer Security & OS Lab, DKU

When software is threatened

In development and maintenance, by

● “Rogue” developer commits sabotage and performs subversion by planting

− malicious code (“ bombs” and other undocumented functions)

− intentional faults, weaknesses, vulnerabilities

− exploitable backdoors, trapdoors

In distribution and deployment, by

● External attackers (intercepting and tampering with distribution)

● Insider threats (administrators intentionally tampering, misconfiguring, planting malware, rootkits, etc.)

In operation, by

● External attackers (level of exposure varies with level of network connectivity/exposure)

● Insider threats (users and administrators abusing privileges, not applying patches)

36Computer Security & OS Lab, DKU

Extra Slide: Terminologies

Software subversion is the process of making software perform unintended actions either by tampering with program code or by altering behavior in another fashion.

● For example, code tampering could be used to change program code to load malicious rules or heuristics, SQL injection is a form of subversion for the purpose of data corruption or theft and buffer overflows are a form of subversion for the purpose of un-authorized access. These attacks are examples of computer hacking.

Anti-Subversion Software detects subversion and attempts to stop the effects of the hack.

● Software applications are vulnerable to the effects of subversion throughout their lifecycle from development to deployment, but particularly in operation and maintenance.

37Computer Security & OS Lab, DKU

Extra Slide: Terminologies

Phase 6: Installation/Deployment:

Once the software testing phase is over and no bugs or errors left in the system then the final deployment process starts. Based on the feedback given by the project manager, the final software is released and checked for deployment issues if any.

Phase 7: Maintenance:

Once the system is deployed, and customers start using the developed system, following 3 activities occur

● Bug fixing - bugs are reported because of some scenarios which are not tested at all

● Upgrade - Upgrading the application to the newer versions of the Software

● Enhancement - Adding some new features into the existing software

38Computer Security & OS Lab, DKU

Categories of attack patterns

Direct attacks

● To exploit known or suspected faults, vulnerabilities, weaknesses, backdoors

● To insert malicious code

● To execute malicious code already embedded in the software

● To observe or reverse engineer the software

Indirect attacks

● Intentional activation of external faults at the software’s boundaries

● Intentional changes to execution environment state − Real-machine이아닌 emulator이나 VM에서수행

● “Hogging” of the software’s processing resources − E.g.) CPU hogging is a problem during its usage when user feels that computer performance is getting

slower and slower. The cause can be excessive load of data or program is running but not enough resource to handle them.

● Sabotage or subversion of external services or defense-in-depth measures on which the software relies− 역공학방지기법을깨뜨리는것: de-obfuscation, unpacking, anti-debugging, …

hogging: 독차지하는것, 독점하는것

39Computer Security & OS Lab, DKU

Attack objectives (desired direct results)

Reconnaissance

● To learn more about the software in order to craft more effective attacks

Subversion

● To change the software’s functionality, by tampering or insertion of logic

Sabotage

● To make the software fail

− suddenly crash or gradually degrade in performance

● To make the software inaccessible

− by moving or deleting its executable

− by corrupting its user interface or communications capability

● Note: changing the executable’s file system permissions would have the same result, but is a system-level threat.

subvert: 전복시키다, 체제를뒤엎다, 파멸시키다.

sabotage: 방해공작을벌이다, 고의로방해하다. 파괴하다, 태업하다.

40Computer Security & OS Lab, DKU

What makes software vulnerable?

It’s big and complicated, and getting more so – humans can no longer fully comprehend it.

Component-based development: COTS, OSS, and reuse means no-one really knows where most of it comes from, or how it was built.

It contains lots of faults and weaknesses. Many of these are exploitable.

It comes in binary executable form, which makes finding those faults and weaknesses a lot harder.

It’s exposed to threats all the time, even while it’s under development.

41Computer Security & OS Lab, DKU

Where vulnerabilities originate (1/2)

During development

● Inadequate or spurious requirements

● Inadequate architecture, assembly option, detailed design

● Use of vulnerable processing models, software technologies

● Insecure use of development tools, languages, libraries

● Use of insecure development tools, languages, libraries

● Poor coding practices

● Coding errors

● Use of vulnerable/unpatched components

● Incorrect or mismatched security assumptions

● Inadequate reviews, testing, assessments

● Sabotaged test results

● Residual backdoors

● Sensitive info about software problems in user-viewable comments/error messages

● Inadequate configuration documentation

● Insecure installation procedures, scripts, tools

42Computer Security & OS Lab, DKU

spurious: 비논리적인, 겉으로만 그럴싸한residual: (어떤 과정이 끝나고 난 뒤에) 남은, 잔여[잔류]의

Malicious code planted during development

Trojan horses ● Software that seems to do one thing, but actually does another

Time bombs ● Software whose execution is triggered at a predefined time (on computer

clock)

Logic bombs● Software whose execution is triggered by a predefined event or input

Malicious undocumented functions (“rotten Easter eggs”)

43Computer Security & OS Lab, DKU

Hard Problem:

Software of Unknown Pedigree (SOUP)

Pedigree: 족보, 내력, 계보, 혈통

44Computer Security & OS Lab, DKU

Where vulnerabilities originate (2/2)

During deployment and operation

Insecure configuration of software and its environment● Environment: OS type & version (DAC/MAC, monolithic/micro-kernel), Environment

variables (home dir., shell, …), runtime environment, TPM 지원여부, …

Inadequate allocation of resources

Failure to apply patches

Software aging● Software aging is usually a consequence of software faults.

● As the runtime period of the SW system or process increases, its failure rate also increases.

45Computer Security & OS Lab, DKU

Secure Software …

Preserves all of its required properties in the face of threats to those properties

● Dependability is the #1 desirable property for all software

− If it doesn’t work correctly and predictably at all times, what good is it?

Can resist and/or tolerate most threats that attempt to subvert or sabotage it● Integrity can be subverted by attacks

● Availability can be sabotaged by attacks

Can terminate, limit the damage, and rapidly recover from the few that succeed

46Computer Security & OS Lab, DKU

Dependability properties

Quality (correctness and predictability)

Reliability

Fault-tolerance

Trustworthiness

Safety (the above intensified: failure threatens human life or health)

47Computer Security & OS Lab, DKU

Security properties

Integrity ● can’t be subverted (subvert: 전복시키다, 체제를뒤엎다, 파멸시키다)

Availability ● can’t be sabotaged (sabotage: 방해공작을벌이다, 고의로방해하다. 파괴하다, 태업하다)

Trustworthiness (신용, 신뢰성, 믿을수있음)

● won’t do the unexpected

− not the same as trustworthiness of software as non-human “user”

Confidentiality (of the software itself) ● as a subject: behaviors, states, actions

● as an object: executable file location, characteristics, contents

● deters reconnaissance, reverse engineering

● less likely to be a requirement for software than for information

Assurability● ability to verify software’s required properties, including security

● aided by smallness, simplicity, traceability

Source: Security Challenges for Systems Built from Nondevelopmental Software Components—Brown Bag 02.22.07

48Computer Security & OS Lab, DKU

What makes software secure?

Attack-resistance

● Components and whole system recognize and resist attack patterns.

● System recognizes suspicious component behavior and either

− isolates/constrains that behavior

− terminates execution of the component

Attack-tolerance

● Components keep operating in spite of errors caused attacks

● System keeps operating in spite of attack-caused component errors/failures

Attack-resilience

● System constrains damage from attacks it could not tolerate, isolates itself from attack source

● System rapidly recovers (at least to minimum acceptable performance)

49Computer Security & OS Lab, DKU

Security throughout the life cycle

Security-enhancing process improvement model

● e.g., FAA iCMM/CMMI safety & security extensions, SSE-CMM− SSE-CMM: Secure Systems Engineering - Capability Maturity Model

Security-enhancing life cycle methodologies

● e.g., CLASP, SDL, McGraw’s 7 Touchpoints, TSP-Secure, AEGIS, RUPSec, SSDM, Oracle Secure SW Assurance, Waterfall-Based SW Security Engineering Process − CLASP: Comprehensive Lightweight Application Security Process

− TSP: Team Software Process

Establishing security entry and exit criteria for each life cycle phase

Including appropriate and sufficient security reviews, analyses, tests at each phase

● e.g., threat models, attack trees, vulnerability analyses, code reviews, black box tests, risk analyses, assurance cases

Secure SCM● SCM: Software Configuration Management

Education, training, awareness, professional certification

QA of security of software processes and practices

50Computer Security & OS Lab, DKU

Secure requirements engineering

Risk-driven vs. functionality-driven:

● non-functional requirements (what software must be, vs. what it must do)− Some typical non-functional requirements

• Performance: Response time, Throughput, Utilization

• Scalability

• Availability / Reliability / Recoverability

● constraint requirements

● negative requirements

− Need to allow time for translating these into requirements for functionality (what can be built/tested)

• e.g., no BOFs = must do input validation; must be fault-tolerant = must have exception handling that...)

− Constraint/Negative requirements place constraints on software functions in order to minimize the likelihood of non-secure software behaviors, usually in terms of things to be avoided or prevented.

• Examples:

The server must not return a restricted web page to a user who is not authorized to access it.

The software must not accept overlong input data.

51Computer Security & OS Lab, DKU

Reducing SW security risk: acquisition

Include security requirements and evaluation criteria in all RFPs

Strict monitoring/control of “non-traditional” acquisitions (e.g., OSS, shareware, freeware downloads)

Supplier and integrator background checks (COTS)● COTS: Commercial off-the-shelf

Supplier and integrator SDLC process reviews

Contract language requiring COTS suppliers to warrant safe, secure product behavior

Pedigree analysis, security testing of all candidate components before (!) purchase (COTS, shareware) or integration (OSS, freeware)

● Ideal world: acquisition policy that favors software with known pedigree

52Computer Security & OS Lab, DKU

Reducing SW security risk: source selection

Analyze individual components

● code review, security tests, vulnerability scans

● identify mismatches of security assumptions in pairs of components (including candidate component and environment component pairs)

● evaluate other evidence (published vulnerability reports/patch history, C&A or CC history, supplier reputation, development process)

− Certification and accreditation (C&A) processes for government information systems are intended to ensure that before a deployed system becomes operational, the system includes security controls and countermeasures that adequately mitigate identified risks.

− Common Criteria (CC)

● identify security/countermeasure requirements for component-based architecture

● determine feasibility and cost of security measures and countermeasures needed to minimize exposure of component vulnerabilities

accreditation: 승인, 인가

53Computer Security & OS Lab, DKU

Secure software architecture and design

System processing model doesn’t preclude secure behaviors, interactions

Minimization of vulnerabilities—quantity and exposure—through security measures and countermeasures (discussed later)

Secure inter-component and extra-system interfaces (APIs, RPCs, UIs)

Prevents excessive trust in high risk (including SOUP) components● SOUP: Software of Unknown Pedigree

Absolutely minimizes privileges granted to all processes/components at all times

Isolates and constrains environment in which high-risk software operates

Minimizes untrusted software access to/interaction with trusted software

54Computer Security & OS Lab, DKU

Secure software architecture and design

Addresses mismatches in components’ assumptions about each other:

● Component A may expect Component B to provide certain

− functionality (e.g., signature validation)

− properties (e.g., fault tolerance)

− outputs (format, length, etc.)

− interfaces (APIs, RPCs, protocols)

Addresses inaccurate assumptions about the environment:

● Component may expect the execution environment to provide

− certain functionality (e.g., PKI)

− certain protection (e.g., sandboxing)

− certain inputs (i.e., environment parameters)

55Computer Security & OS Lab, DKU

Security issues of component-based software

Mismatches in component assumptions about each other and execution environment: Component may expect …

● certain functionality in another component (e.g., signature validation)

● certain functionality in the environment (e.g., PKI)

● certain properties in other components (e.g., fault tolerance)

56Computer Security & OS Lab, DKU

Sources of inaccurate assumptions (1/2)

Incomplete, omitted, overly-general, or poorly-stated functionality-constraining and nonfunctional property requirements

Failure to translate such requirements into actionable requirements

Architecture and design that do not satisfy their actionable non-functional (property) and negative (constraint) requirements

Ignoring the security implications of different languages, tools, and technologies, and how they are used in implementing the software

Failure to evaluate security of non-developmental components, alone and in combination with other components, before selection

Security reviews/tests not included in each SDLC phase

57Computer Security & OS Lab, DKU

Sources of inaccurate assumptions (2/2)

Test cases limited to normal operating conditions

Lack of risk-driven security testing, i.e., abnormal conditions, test cases based on attack patterns

Lack of stress testing, i.e., abnormal activity, inputs, etc. to validate design assumptions

Inadequate preparation of the software for distribution/deployment

No verification that security standards have been conformed to

Software design does not match intended operational environment

Conform: (규칙·법등에) 따르다[맞다]. ~에일치하다.

Conformance: 일치, 부합, 적합성

58Computer Security & OS Lab, DKU

SOUP = inaccurate security assumptions

Unable to infer component trustworthiness from knowledge of development process

Unable to infer component trustworthiness from supplier reputation

Disjoint product and patch release schedules

Disjoint supplier priorities vs. system requirements

Publishing of known vulnerabilities: attackers know at least as much as system developers

● Attackers don’t care about license Ts&Cs “preventing” reverse engineering, which means they probably know much more.− Ts&Cs: Terms and Conditions

Potential hostile foreign influence on offshore developers may result in products with embedded malicious code, rotten Easter eggs, intentional vulnerabilities

disjoint: (형용사)<두집합이> 공통원소를갖지않은, (동사) …의관절을삐게하다, 탈구시키다, (낱낱으로) 해체하다.

offshore: ((돈·기업등이)) 역외의(세율및법규제가유리한지역에서운용하는), 국외의,

59Computer Security & OS Lab, DKU

Reduce SOUP risk: architecture

Define different candidate system architectures in which to evaluate components, model component risks

● include threat, attack, vulnerability modeling for each candidate architecture

● evaluate both architecture and components together

− architecture provides framework for revealing inter-component behaviors, assumption (mis)matches

− candidate components verify security of architecture-defined component combinations, configurations, process flows

60Computer Security & OS Lab, DKU

Secure implementation and testing

Secure coding practices supported by tools

Write, acquire, reuse only components proven dependable, free of exploitable faults and weaknesses

Security testing

● White box:

− static and dynamic code analysis

− fault injection/propagation analysis

● Black box

− fault injection

− fuzzing

− penetration testing

− vulnerability scanning

61Computer Security & OS Lab, DKU

Reduce SOUP risk: testing, risk management

Black box—and when source code is available, white box—security testing

● individual components

● pairs of components

● whole system

Ongoing risk analysis and reengineering

● find known-pedigree components with required capabilities to replace SOUP

● redesign system so SOUP components’ capabilities are no longer needed

● apply new countermeasures to further reduce SOUP component risk

62Computer Security & OS Lab, DKU

Secure distribution, deployment, maintenance

Trusted distribution techniques ● code obfuscation

● digital watermarking

● code signing

● authenticated, encrypted download channels

Install. configuration that ensures● secure interactions with execution environment

● adequate allocation and safe management of environment resources

Maintenance● impact analyses of new requirements, own and supplier updates, patches

● ongoing risk assessment to identify new requirements

● forensic analysis (post-incident) to identify new requirements

63Computer Security & OS Lab, DKU

SW security measures and countermeasures (1/2)

Programmatic

● input and output validation wrappers

● obfuscation (to deter reverse engineering)

● secure exception handling (in custom software)

● fault tolerance measures

− redundancy

− diversity (redundancy using different components with comparable functions)

Development tools and languages

● type-safe languages

● safe versions of libraries

● secure compilers

● secure compilation techniques

programmatic: (격식) 계획[프로그램]의, 계획에따른

64Computer Security & OS Lab, DKU

SW security measures and countermeasures (2/2)

Environment-level measures

● virtual machines/sandboxes

● chroot jails

● trusted OS with mandatory integrity policy/compartments

● secure microkernels

● TPMs

● program shepherding: a method for monitoring control flow transfers during program execution to enforce a security policy

● altered memory maps

● system call filters

Add-ons

● code signing with signature validation

● obfuscation and digital watermarking (to deter reverse engineering)

● malware/spyware scanners (host level)

● application security gateways/firewalls

● intrusion detection/prevention (network and host based)

65Computer Security & OS Lab, DKU

Secure Software & Security Threats

Commercial security is reactive.

Building secure software• Enhancing the development life cycle to produce secure software,

SW Assurance Forum, Oct. 2008

Computer Security & OS Lab, DKU 66

What makes software secure?

Attack-resistance

● Components and whole system recognize and resist attack patterns.

● System recognizes suspicious component behavior and either

− isolates/constrains that behavior

− terminates execution of the component

Attack-tolerance

● Components keep operating in spite of errors caused attacks

● System keeps operating in spite of attack-caused component errors/failures

Attack-resilience

● System constrains damage from attacks it could not tolerate, isolates itself from attack source

● System rapidly recovers (at least to minimum acceptable performance)

67Computer Security & OS Lab, DKU

The Challenge of Building Secure Software

To be considered secure, software must exhibit three properties:

1. Dependability: Dependable software executes predictably and operates correctly under all conditions, including hostile conditions, including when the software comes under attack or runs on a malicious host.

2. Trustworthiness: Trustworthy software contains few if any vulnerabilities or weaknesses that can be intentionally exploited to subvert or sabotage the software’s dependability.

● In addition, to be considered trustworthy, the software must contain no malicious logic that causes it to behave in a malicious manner.

3. Survivability (also referred to as “Resilience”): Survivable—or resilient—software is software that is resilient enough to (1) either resist (i.e., protect itself against) or tolerate (i.e., continue operating dependably in spite of) most known attacks plus as many novel attacks as possible, and (2) recoveras quickly as possible, and with as little damage as possible, from those attacks that it can neither resist nor tolerate.

68Computer Security & OS Lab, DKU

Security Threats

69Computer Security & OS Lab, DKU

Identifying/classifying security threats (security attacks)

Security Threats

70Computer Security & OS Lab, DKU

Identifying/classifying security threats (security attacks)● Microsoft STRIDE model

● Attacks against security goals

Microsoft STRIDE chart

71Computer Security & OS Lab, DKU

Security Services

Relation between STRIDE security attributes and security service

72Computer Security & OS Lab, DKU

Software Security

The practice of building software to be secure and to function properly under malicious attack

● The idea of engineering software so that it continues to function correctly under malicious attack

● Software security unifies the two sides of software security – attack and defense, exploiting and designing, breaking and building – into a coherent whole

− Software security requires a careful balance

73Computer Security & OS Lab, DKU

Cost, Effort and Time for Fixing Vulnerabilities

74Computer Security & OS Lab, DKU

Software Security

Cyber criminals use flaws in software and exploit them for their own malicious intents

What is software security?● Its all about building secure software!

● The process of designing, building, and testing software for security

● Taking the pro-active approach: building security INTO the software as opposed to securing it after building it

Software security is● the idea of engineering software so that it continues to function correctly

under malicious attack

● about building secure software: designing software to be secure, making sure that software is secure and educating software developers, architects and users about how to build secure things

75Computer Security & OS Lab, DKU

Software security vs. Application security

Software security

● the process of designing, building and testing software for security

− identifies and expunges problems in the software itself

Application security

● about protecting software and the systems that software runs in a post facto way, after development is complete.

− Issues critical to this subfield include sandboxing code (as the Java virtual machine does), protecting against malicious code, obfuscating code, locking down executables, monitoring programs as they run (especially their input), enforcing the software use policy with technology and dealing with extensible systems.

● Application security follows naturally from a network-centric approach to security, by embracing standard approaches such as penetrate and patch and input filtering (trying to block malicious input) and by providing value in a reactive way.

− Put succinctly, application security is based primarily on finding and fixing known security problems after they’ve been exploited in fielded systems.

Source: https://www.cigital.com/blog/software-security/

76Computer Security & OS Lab, DKU

Summary

Software is everywhere

Define vulnerabilities and exploits● Security threats

SDLC (Software Development Lifecycle)

Software security

Security in the Software Development Lifecycle, Hala Assal and Sonia Chiasson, Carleton University, Aug. 2018.● https://www.usenix.org/conference/soups2018/presentation/assal

77Computer Security & OS Lab, DKU

A Key Comment

• Do not try attacks at home or school!

• Our goal is to educate so you can defend, not attack

78Computer Security & OS Lab, DKU